Bug 299398

Summary:	shadow on volume OSD is wrong the first time
Product:	[Plasma] kwin	Reporter:	Mark <markg85>
Component:	compositing	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:	4.10
Sentry Crash Report:
Attachments:	screenshot that demonstrates the issue glxinfo

Description Mark 2012-05-04 19:03:12 UTC

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.

Comment 1 Thomas Lübking 2012-05-04 19:23:08 UTC

These shadows are part of and drawn by the window - can you make a screenshot?

Comment 2 Mark 2012-05-04 19:34:48 UTC

Created attachment 70861 [details]
screenshot that demonstrates the issue

Comment 3 Mark 2012-05-04 19:37:04 UTC

(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.

Comment 4 Thomas Lübking 2012-05-04 19:38:58 UTC

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")?

Comment 5 Mark 2012-05-04 19:50:57 UTC

(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?

Comment 6 Thomas Lübking 2012-05-04 19:59:41 UTC

try deactivating the blur effect

Comment 7 Mark 2012-05-04 20:05:05 UTC

(In reply to comment #6)
> try deactivating the blur effect

Bingo, jackpot!
Deactivating blur fixes the issue. Obviously that's not a "fix" ;-)

Comment 8 Thomas Lübking 2012-05-04 20:09:20 UTC

- 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?

Comment 9 Mark 2012-05-04 20:18:23 UTC

(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.

Comment 10 Thomas Lübking 2012-05-04 20:34:51 UTC

(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?

Comment 11 Mark 2012-05-04 20:38:41 UTC

Created attachment 70864 [details]
glxinfo

Comment 12 Mark 2012-05-04 20:42:10 UTC

(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/

Comment 13 Thomas Lübking 2012-05-04 20:53:50 UTC

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?

Comment 14 Mark 2012-05-04 20:57:20 UTC

(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 ;-)

Comment 15 Martin Flöser 2013-01-09 09:18:47 UTC

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).