Hi, What happens is likely a corner case and very difficult to track down. As soon as you're logged into KDE and press mute or volume up/down you will see that the shadow for the OSD widget is wrong the first time. After that is just works fine. Reproducible: Always Steps to Reproduce: 1. Login to your session 2. Press mute 3. Observe wrong shadow the first time you press mute Actual Results: The shadow is rendered wrongly. Expected Results: The shadow should be rendered correctly Detail, it only seems to be rendered wrongly at the bottom of the osd widget. The rest seems to be fine. KWin info: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: AMD Radeon HD 6800 Series OpenGL version string: 2.1 (4.2.11631 Compatibility Profile Context) Driver: Catalyst Driver version: 2.1 GPU class: NI OpenGL version: 2.1 X server version: 1.11.4 Linux kernel version: 3.3.4 Direct rendering: no Requires strict binding: yes GLSL shaders: no Texture NPOT support: yes If you need more information, feel free to ask. I also happily test out your patches to see if it resolves it.
These shadows are part of and drawn by the window - can you make a screenshot?
Created attachment 70861 [details] screenshot that demonstrates the issue
(In reply to comment #1) > These shadows are part of and drawn by the window - can you make a > screenshot? Ahh sorry. I forgot to add it. Added now. And it's only occurring the _first_ time you press mute (or vol up/down). So if you 't see it i recommend that you logout and back in again to see it.
Looks like uninitialized pixmap - can you try suspending compositing, run xcompmgr and call the OSD (it should be translucent and have shadows, the interesting question is whether they're broken) and/or select the xrender backend ("kcmshell4 kwincompositing")?
(In reply to comment #4) > Looks like uninitialized pixmap - can you try suspending compositing, run > xcompmgr and call the OSD (it should be translucent and have shadows, the > interesting question is whether they're broken) and/or select the xrender > backend ("kcmshell4 kwincompositing")? Done. With xcompmgr : No shadows at all - anywhere! - but also no bug in the shadows :p With xrender : Shadows work just fine and no visible bug. With OpenGL : there is the bug again... Anything else that i can test for you?
try deactivating the blur effect
(In reply to comment #6) > try deactivating the blur effect Bingo, jackpot! Deactivating blur fixes the issue. Obviously that's not a "fix" ;-)
- try "KWIN_DIRECT_GL=1 kwin --replace&" and activate OpenGL2 shaders - does the radeon driver support your GPU? (xf86-video-ati) - what happens if you draw the blur strength to the lowest possible value?
(In reply to comment #8) > - try "KWIN_DIRECT_GL=1 kwin --replace&" and activate OpenGL2 shaders I can't reliable test that one. It requires me to have konsole open to restart kwin and that "might" cause the shadow to somehow just work. > - does the radeon driver support your GPU? (xf86-video-ati) Yes it does. However, the amount of noise that is coming from my card is not fun with that oss driver. Without proper power management that driver is sadly close to useless for desktop usage. > - what happens if you draw the blur strength to the lowest possible value? Interesting! If i change it to the lowest value the issue also seems to be "fixed". Putting it back to the second biggest (and biggest) value makes the issue visible again. I haven't tried other values in between.
(In reply to comment #9) > (In reply to comment #8) > > - try "KWIN_DIRECT_GL=1 kwin --replace&" and activate OpenGL2 shaders > I can't reliable test that one. It requires me to have konsole open to > restart kwin and that "might" cause the shadow to somehow just work. you can #!/bin/sh export KWIN_DIRECT_GL=1 in some 740 file in .kde[4]/env for the same effect. Notice that direct rendering might still have issues in fglrx, so keep that in mind and remove it in case of other trouble. > Interesting! If i change it to the lowest value the issue also seems to be > "fixed". might be bug #284984 - just try what strength works and please attach "glxinfo -l > my.glxinfo" Did this occur with a recent update?
Created attachment 70864 [details] glxinfo
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > - try "KWIN_DIRECT_GL=1 kwin --replace&" and activate OpenGL2 shaders > > I can't reliable test that one. It requires me to have konsole open to > > restart kwin and that "might" cause the shadow to somehow just work. > you can > > #!/bin/sh > export KWIN_DIRECT_GL=1 > > in some 740 file in .kde[4]/env for the same effect. Notice that direct > rendering might still have issues in fglrx, so keep that in mind and remove > it in case of other trouble. Just by trying it in the command line i got a dog slow compositing. So i rather avoind adding that. > > > Interesting! If i change it to the lowest value the issue also seems to be > > "fixed". > might be bug #284984 - just try what strength works and please attach > "glxinfo -l > my.glxinfo" > Did this occur with a recent update? Well, I've noticed this since all of the KDE 4.8 cycle. Don't know from before that. Funny fact, i actually added the blurred background in the OSD volume thing: https://svn.reviewboard.kde.org/r/6770/
ok, this: GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 ... GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 ... GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB = 2147483647 looks a "tiny" bit ambitious - i tend to believe this is a dupe of bug #284984 but wonder why it only should happen on the first pass then (possibly because of the windows blur region?) Other blurring (eg. with bespin/oxygen-transparent) works fine?
(In reply to comment #13) > ok, this: > GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 > ... > GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 > ... > GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB = 2147483647 > GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB = 2147483647 > > looks a "tiny" bit ambitious - i tend to believe this is a dupe of bug > #284984 but wonder why it only should happen on the first pass then > (possibly because of the windows blur region?) > Other blurring (eg. with bespin/oxygen-transparent) works fine? No issues on any other place that i can see... But yeah, those values look wrong unless the max integer size is commonly used in opengl ;-)
The shadow rendering code for Plasma styled elements changed in 4.10 which should bypass the effects described in this bug report. In case you still see this with 4.10 please reopen (note: if you are running a current RC - shadows are broken, so you need to wait at least till RC 3).