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.
Created attachment 71517 [details] Screenshot
Created attachment 71518 [details] glxinfo
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.
I had 4.8.3 installed until yesterday, then upgraded to KDE 4.8.80. Before, everything worked fine.
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
Created attachment 71519 [details] wm console output Here you go
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
Tested without shaders, now the rectangle is white instead of black.
please try switching to the "raster" graphics system. There's a switch for it in the advanced compositing settings since 4.9
With the raster graphics system it works fine.
*** Bug 301078 has been marked as a duplicate of this bug. ***
I just switched to native and am seeing it on radeon as well.
I get some "failed to create drawable" errors with native when trying to use an EffectFrame
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)
No! But *this* here is the explicit target selection (which is eg. blocked for r300) in Texture::load(Pixmap, .)
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) { .... }
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 ;-)
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.
@Thomas So, if I understood you correctly, the patch to try would consist in commenting out the entire explicit texture target specification block?
yupp, that alone should be enough
Ok, I'll start compiling and report back tomorrow.
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.)
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);
Black again...
*** Bug 301383 has been marked as a duplicate of this bug. ***
t'is a dupe *** This bug has been marked as a duplicate of bug 296289 ***
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.
Patch rebased and applied to 4.8.90, but still black :s
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...
Btw. the problem is not reproducable with kwin_gles and native graphic system