Bug 301068

Summary: Outline effect renders black
Product: kwin Reporter: Sandro Mani <manisandro>
Component: scene-openglAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: kde, lasall42, yyc1992
Priority: NOR Keywords: regression
Version: 4.8.80Flags: mgraesslin: Intel+
mgraesslin: r600g+
Target Milestone: 4.9 Beta 2   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Screenshot
glxinfo
wm console output
Attempted patch
patch attempt using glplatfomr NPOT

Description Sandro Mani 2012-06-02 17:44:52 UTC
Using kde-workspace-4.8.80-4.fc18.x86_64

When the outline which appears when one drags a window to a screen corner renders black. When disabling the Outline plugin, the black rectangle does not appear.

This is a regression compared to 4.8.3.

Attachments:
- Screenshot
- glxinfo

Reproducible: Always

Steps to Reproduce:
1. Enable Outline plugin
2. Drag a window to the screen corner
3.
Comment 1 Sandro Mani 2012-06-02 17:46:14 UTC
Created attachment 71517 [details]
Screenshot
Comment 2 Sandro Mani 2012-06-02 17:46:35 UTC
Created attachment 71518 [details]
glxinfo
Comment 3 Martin Flöser 2012-06-02 17:49:12 UTC
I have seen this issue as well, but only on the Intel powered system. No issue with AMD or NVIDIA, so I think it's an Intel related issue. If you are sure that with the same driver it worked with 4.8, then I have an idea where to look.
Comment 4 Sandro Mani 2012-06-02 17:59:25 UTC
I had 4.8.3 installed until yesterday, then upgraded to KDE 4.8.80. Before, everything worked fine.
Comment 5 Martin Flöser 2012-06-02 18:13:26 UTC
ok, could you give me some more info about the system? Please open Alt+F2 -> "wm console"

This opens the javascript console. Type the following command:
print(workspace.supportInformation())

Click execute and please attach the output to the bug report
Comment 6 Sandro Mani 2012-06-02 18:16:15 UTC
Created attachment 71519 [details]
wm console output

Here you go
Comment 7 Thomas Lübking 2012-06-02 18:30:42 UTC
also disable opengl 2 shaders.

my random guess is that it'll also bypass this issue but rather do so anyway, since they might (likely) cause bad performance on that GPU
Comment 8 Sandro Mani 2012-06-02 18:32:41 UTC
Tested without shaders, now the rectangle is white instead of black.
Comment 9 Martin Flöser 2012-06-02 18:36:46 UTC
please try switching to the "raster" graphics system. There's a switch for it in the advanced compositing settings since 4.9
Comment 10 Sandro Mani 2012-06-02 18:54:28 UTC
With the raster graphics system it works fine.
Comment 11 Martin Flöser 2012-06-03 06:49:18 UTC
*** Bug 301078 has been marked as a duplicate of this bug. ***
Comment 12 Martin Flöser 2012-06-03 12:09:28 UTC
I just switched to native and am seeing it on radeon as well.
Comment 13 Martin Flöser 2012-06-03 12:13:27 UTC
I get some "failed to create drawable" errors with native when trying to use an EffectFrame
Comment 14 Thomas Lübking 2012-06-03 15:30:06 UTC
Not sure whether it's related but the *unstyled* effectframe (only) looks weird on nvidia/native too (the borders are far to translucent - GLSL is irrelevant)
Comment 15 Thomas Lübking 2012-06-03 16:35:19 UTC
No!
But *this* here is the explicit target selection (which is eg. blocked for r300) in Texture::load(Pixmap, .)
Comment 16 Thomas Lübking 2012-06-03 16:49:10 UTC
Explicitly selecting that GLX_TEXTURE_RECTANGLE_EXT junk, to be more precise 

The i945 is invalidly detected to only support limited NPOT (what iirc reads "texture_rect only")
Forcing a *sane* texture format that did not come over us right ... i'm drifting - forcing GLX_TEXTURE_2D_EXT fixes it for me.

@Sandro
The i965 is detected for NPOT support, but can you try omitting the explicit target selection?
You'll find it in scene_opengl_glx.cpp:742 in "SceneOpenGL::Texture::load(.) - it's this block:
// Specifying the texture target explicitly is reported to cause a performance
// regression with R300G (see bug #256654).
if (GLPlatform::instance()->driver() != Driver_R300G) {
 ....
}
Comment 17 Thomas Lübking 2012-06-03 17:06:59 UTC
Me and my fury... :-(
Comment #16 is WRONG (tricked myself on the graphicssystem) yet
Comment #15 remains CORRECT - not explicitly selecting the target type *does* fix it here.

Consequence is that such patch will very likely bypass/fix it and there's no NPOT weirdness.
@Sandro:
can you apply one for testing?


Sorry for the noise and the rant, the texture_rect_arb is shit nevertheless ;-)
Comment 18 Thomas Lübking 2012-06-03 17:18:55 UTC
Mehhhh - it's worse:
forcing texture_rect_arb fixes it as well (2D was chosen for the POT dimensions) BUT it completely breaks the unstyled texture (though no GLSL is in use)
I'll now shut up.
Comment 19 Sandro Mani 2012-06-03 23:03:55 UTC
@Thomas
So, if I understood you correctly, the patch to try would consist in commenting out the entire explicit texture target specification block?
Comment 20 Thomas Lübking 2012-06-03 23:05:57 UTC
yupp, that alone should be enough
Comment 21 Sandro Mani 2012-06-03 23:12:23 UTC
Ok, I'll start compiling and report back tomorrow.
Comment 22 Sandro Mani 2012-06-04 20:40:18 UTC
Created attachment 71586 [details]
Attempted patch

So, with the patch (which I attached), I ended up with a completely black screen as soon as I switched to native graphics system. (This did not occur before, and also does not occur now after downgrading again.)
Comment 23 Thomas Lübking 2012-06-04 21:00:40 UTC
great :-(

what happens if you just omit the attrs parameter:
- d->m_glxpixmap = glXCreatePixmap(display(), fbcdrawableinfo[ depth ].fbconfig, pix, attrs);
+ d->m_glxpixmap = glXCreatePixmap(display(), fbcdrawableinfo[ depth ].fbconfig, pix, 0);
Comment 24 Sandro Mani 2012-06-05 00:23:13 UTC
Black again...
Comment 25 Thomas Lübking 2012-06-07 17:35:27 UTC
*** Bug 301383 has been marked as a duplicate of this bug. ***
Comment 26 Thomas Lübking 2012-06-09 12:42:54 UTC
t'is a dupe

*** This bug has been marked as a duplicate of bug 296289 ***
Comment 27 Thomas Lübking 2012-06-09 20:03:04 UTC
Created attachment 71687 [details]
patch attempt using glplatfomr NPOT

the attached patch works for me (see bug #296289) but i've no idea whether it's a general solution or only covers a particular (sub)issue.
If you can, please try and report - thanks.
Comment 28 Sandro Mani 2012-06-10 21:38:31 UTC
Patch rebased and applied to 4.8.90, but still black :s
Comment 29 Thomas Lübking 2012-06-10 21:42:36 UTC
We meanwhile have more insight on this - at least for another person on a SandyBridge HD chip only forcing down NPOT (ie. replace "GLTexture::NPOTTextureSupported()" with "false") worked (but breaks GLSL ...)
There's sth. odd going on here since the GPU should be capable of NPOT textures but seems not - or the texture is wrongly addressed later on...
Comment 30 Martin Flöser 2012-06-13 07:31:14 UTC
Btw. the problem is not reproducable with kwin_gles and native graphic system