ftp://cetaura.com/out-2.ogv

Movie with the menus behaviour. The few seconds blip at 1:00 is caused by disabling compositing with the computer under load.

a) A trivial workaround would be to setup some animation effect for showing windows/popups
b) Sounds like bug #264259, but: "OpenGL version string: 2.1 Mesa 8.0" - does it happen with mesa 7.1x as well?
c) In the video it seems menus are often displayed blank before being filled with text - ensure "GUIEffects=none" in ~/.config/Trolltech.conf, section [qt]
d) does it happen when disabling v'sync?

Hi,
Disabling VSync fixes it, thank you for the workaround.

It is not Qt4 related, the problem happens also with Amarok 1.x and GTK programs like Pidgin. I'll try to come back with details about Mesa.

Alex

I also have this bug.
Switching to XRender fixes the issue, however with OpenGL compositing I get invisible menus.

since vsync'ing changed alot in 4.9, please confirm the issue for that version

@Alessandro:
"Me too" is best accomplished by the used version, settings and in this case whether the workaround worked as well ;-)

I have this issue too. It's always reproducible in Opera browser, but I never met it in another application. Switching vsync does nothing for me. Just download opera and right click in the main window. There is another bug: open 2 tabs and try to hover over it, you'll get blinking, but this can be fixed via -noargb command line.

I have KDE 4.9 with intel HD3000 (sandy bridge) and mesa 8.0.4

*** Bug 305360 has been marked as a duplicate of this bug. ***

Hi,
I was wrong in my previous comment, disabling VSync does not completely
fix this. It still happens sometimes, for example with VirtualBox,
sometimes Amarok and Opera.
I'll report back when my distro gets KDE 4.9.
Alex

On 08/19/2012 09:22 PM, Thomas Lübking  wrote:

That's weird, but I just deleted my kwinrc and everything works fine. I saw your video and I think it's a theme-specific or something, as opera uses the theme you use.

The issue is likely that the window is ARGB and not really painted when mapping and doesn't send damage events after it's actually done either.

We consider to schedule the visual mapping for a few ms to compensate that. See bug #305360

Hi,

Has this bug been fixed after all? It has been tormenting me for months now. Here's a video:

http://www.youtube.com/watch?v=FEcPKWulVU0

In my case, the problem happens both on my laptop (Radeon graphics card using the free radeon driver) and on my desktop (Nvidia graphics card using the proprietary nvidia driver). Both systems are running Debian Wheezy with KDE 4.8.4, but the problem has been present at least since KDE 4.7 (probably KDE 4.6 as well). The problem happens with both KDE and GTK applications, mainly with pop-up type things (like menus, context menus, kmix's volume slider, etc). As with others, in my case the problem doesn't happen if I switch to Xrender compositing for the desktop effects.

As suggested in bug 305360, activating the fade effect seems to solve the problem (I haven't done much testing after enabling the effect). That's probably why it solved the problem for valdikss; deleting the kwinrc file re-enables the fade effect.

Thanks a lot,

Adriano

See comment #11 (the one right above yours...)

There's unlikely a fix - we'll have to workaround it.

For gtk+ it seems to depend on whether the menu has a separator (here, eg. the create submenu of file in gimp causes this for sure) and happens with the Xrender backend just as well (nvidia) what makes perfect sense if the client forgets to yell "here! i reshaped/moved/repainted - update me!"

I've however never seen this in a Qt application.

Well, I don't know exactly what I've done, but I deleted kwinrc and re-enabled fade effect multiple times. Now it works correctly with menus and with sliding popup in opera (it was blinking before that). I'll try to get this working configuration again but it always happens on clean installation.

@Thomas Lübking

I saw comment 11 but didn't really understand what you were saying there. I actually read the whole thread before posting.

Anyway, by working around the bug, do you mean implementing the solution suggested in comment 11 of bug 305360? Or do you mean that we users will have to work around it ourselves (by activating the fade effect, for example)?

In my case, this problem affects both GTK and Qt applications. One of the worst ones is kmix's volume slider, which rarely gets rendered properly. Here's a video showing the problem affecting dolphin:

http://www.youtube.com/watch?v=MS6ykww5Lhw&feature=youtu.be

This is on my laptop, with an ATI Radeon card running the free radeon driver. I'm running Debian Wheezy, with KDE 4.8.4.

The problem doesn't happen if I use KDE with another window manager, such as xfwm4, for example.

Thank you,

Adriano

(In reply to comment #15)
Try to create new user and login to kde to see what's happening with clean profile. And by the way, blinking in opera returned.

In my case, simply enabling the fade effect seems to have solved the problem. So far so good.

(In reply to comment #15)
> Anyway, by working around the bug, do you mean implementing the solution
> suggested in comment 11 of bug 305360?

(In reply to comment #11)
>> We consider to schedule the visual mapping for a few ms to compensate that.

> Or do you mean that we users will
> have to work around it ourselves (by activating the fade effect, for
> example)?
That'd be no workaround but to suggest to omit the option to have no show up animation)
Enforcing such animation would be a solution, but no reasonable one (given the XSYNC extension was added and is supported for at least "regular" clients to prevent similar issues)
 
> In my case, this problem affects both GTK and Qt applications. One of the
> worst ones is kmix's volume slider, which rarely gets rendered properly.
That's some plasma popup - not a regular popup menu.
I didn't try that.

> Here's a video showing the problem affecting dolphin
I don't say i don't believe you, but just that i've never seen this.
Wild guess: try 

     pkill dolphin; QT_NO_GLIB=1 dolphin

still an issue?

> The problem doesn't happen if I use KDE with another window manager, such as
> xfwm4, for example.
It will not happen w/o compositing, as so. suggested also not with XRender compositing and also not if the WM schedules the initial map (I "stole" that idea from E17 where it's a config option

Whoops i've got it in Opera again.
http://i.imgur.com/Fc0xB.png
http://i.imgur.com/0sv85.png

I don't know the cause of this. Sometimes while sliding the tabs everything is blinking, sometimes menus are not painted correcly. It seems random to me.

try "XLIB_SKIP_ARGB_VISUALS=1 opera"

> Sometimes while sliding the tabs everything is blinking
And i've no idea what either "sliding the tabs" nor in this context "blinking" is supposed to mean.

XLIB_SKIP_ARGB_VISUALS=1 opera didn't help.
tab sliding is another bug I believe, as it can be fixed with opera -noargb

I have two kwinrcs. One is broken for me, one is working for me:
http://rghost.ru/39943494 - broken
http://rghost.ru/39943499 - working
With the broken one I have what you can see on screenshots above, and with working menus are as it should be.

Seems like enabling "Taskbar thumbnails" fixes this issue for me in opera.

*** Bug 305656 has been marked as a duplicate of this bug. ***

Ideally someone else would test the patch as well.

https://git.reviewboard.kde.org/r/106173/

Thomas, can you check bug 304990 and bug 305831 ? Interestingly, it seems to happen with Konqueror a lot, maybe because there the oxygen animations are disabled?

No, thatt's the "nvidia black windows bug" which i've not seen in years.

The difference in the two reports is that in one the window is 24bit and in the other it's 32bit

This will not change with eg. the fade in animation or when you trigger updates by hovering items, what makes it different from this bug.

It's usually a VRAM issue (you don't have enough, and get a junk texture in return) - often happens with stuff that raises VRAM demands like blurring etc.

Git commit 0b7e46ddd6d3894f246512429b7a03e10fb3f53d by Thomas Lübking.
Committed on 24/08/2012 at 23:03.
Pushed by luebking into branch 'KDE/4.9'.

delay unsynced window ready_for_painting state

by at max 50ms (and thus trigger a full repaint with the state change)
REVIEW: 106173
FIXED-IN: 4.9.1

M  +2    -0    kwin/client.cpp
M  +10   -0    kwin/composite.cpp
M  +16   -6    kwin/effects.cpp
M  +1    -0    kwin/effects.h
M  +7    -1    kwin/toplevel.cpp
M  +3    -1    kwin/toplevel.h
M  +1    -0    kwin/unmanaged.h

http://commits.kde.org/kde-workspace/0b7e46ddd6d3894f246512429b7a03e10fb3f53d

Git commit e617f176d1e293abcaafbb14d0afcf8aee24f054 by Thomas Lübking.
Committed on 24/08/2012 at 23:03.
Pushed by luebking into branch 'master'.

delay unsynced window ready_for_painting state

by at max 50ms (and thus trigger a full repaint with the state change)
REVIEW: 106173
FIXED-IN: 4.9.1

M  +2    -0    kwin/client.cpp
M  +10   -0    kwin/composite.cpp
M  +16   -6    kwin/effects.cpp
M  +1    -0    kwin/effects.h
M  +7    -1    kwin/toplevel.cpp
M  +3    -1    kwin/toplevel.h
M  +1    -0    kwin/unmanaged.h

http://commits.kde.org/kde-workspace/e617f176d1e293abcaafbb14d0afcf8aee24f054

@Thomas Lübking
(In reply to comment #18)

I tried what you suggested

pkill dolphin; QT_NO_GLIB=1 dolphin

and that didn't solve the problem. I discovered something interesting though: I changed the widget style in System Settings from Cleanlooks (my default choice) to Oxygen and the problem seems to have gone away in Qt applications. When I switch the widget style back to Cleanlooks the problem comes back.

could just be that oxygen uses ARGB popups - it will most likely be worked around by that commit, though

I can confirm what Adriano Viela discovered.
I changed the widget style to "Plastique", I always do this because some effects of the oxigen annoys me.

So to reproduce this bug you have to turn off the Fade effect and change the widget style too.

I could perfectly reproduce it using gtk+ (and one gimp menu for sure) - it's gone with the patch. (i cannot reproduce it any longer - i'd have to revert the patch)

Whatever funny client behavior causes this (might next to the style depend on a couple of things such as the Qt version, the architecture, esp. the used graphicssystem and whatnot) is also pretty irrelevant - it can happen, thus needs to be handled (esp. since gtk+ would unlikely be fixed in that regard ever(?), yet is still a relevant toolkit)

If you want, you might try whether
      XLIB_SKIP_ARGB_VISUALS=1 dolphin
exposes this with oxygen as well (prevents the usage of transparent windows in this dolphin process)

Hi,

In my case, doing

XLIB_SKIP_ARGB_VISUALS=1 dolphin

doesn't cause the problem when using the Oxygen widget style. I did some more testing and discovered that, at least on my system, the Oxygen widget style is the only one that is not affected by this problem. All others (CDE, Cleanlooks, GTK+ Style, MS Windows 9x, Motif, Phase and Plastik) are affected.

Thomas, do you think this somehow caused by GTK? If so, maybe we should let the GTK developers know about it, even if it's irrelevant now that you have worked around the bug.

*** Bug 306195 has been marked as a duplicate of this bug. ***

*** Bug 295769 has been marked as a duplicate of this bug. ***

*** Bug 302961 has been marked as a duplicate of this bug. ***

I have not tested the attached patch. Just reporting in to say that I'm suffering from this problem.  Can this patch be backported to Debian Wheezy (KDE 4.8.4)?


GTK Menus randomly fail to render properly.

1. Set theme to Plastik
2. Enable Desktop Effects KWIN
3. In the "All Effects" tab of KWIN, make sure no effects are checked.
4. Start up a GTK application such as dia, firefox, iceweasel, synaptic
5. Click on a menu and then use left and right arrow keys to scroll back 
and forth through the menus. Randomly, the menus will only partially rendor or not render at all.

Resolution:  
1. Go into "All Effects" tab of KWIN
2. Enable "FADE" effect.

Again, I have not tested the attached patch and I am looking for guidance.

(In reply to comment #37)
> I have not tested the attached patch. Just reporting in to say that I'm
> suffering from this problem.  Can this patch be backported to Debian Wheezy
> (KDE 4.8.4)?
you have to direct this question to the Debian developers. We unfortunately do not control the release (note KDE already released 4.8.5) of Debian.