Bug 295254 - Menus and tooltips are sometime displayed incompletely
Summary: Menus and tooltips are sometime displayed incompletely
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 4.7.4
Platform: Debian unstable Linux
: NOR normal
Target Milestone: 4.9.1
Assignee: KWin default assignee
URL:
Keywords:
: 295769 302961 305360 305656 306195 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-03 11:53 UTC by Alex Dănilă
Modified: 2012-10-14 09:55 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.1
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Dănilă 2012-03-03 11:53:21 UTC
User-Agent:       Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.10.229 Version/11.61
Build Identifier: 4:4.7.4-1

Menus and tooltips are many times not displayed completely (or not at all). Menus can be forced to refresh by hovering each of the entries, but tooltips cannot be refreshed in any way. I associate this with OpenGL compositing, because I can't replicate it otherwise. An example can be seen in the movie.

I believe this happens since 4.6.x, but I cannot guarantee. Different Mesa versions didn't appear to have an influence.

Reproducible: Always

Steps to Reproduce:
Seems to happen only on my computer, so "happens every time" is relative:
1.Enable OpenGL compositing (XRender doesn't appear to have the problem)
2.Open any application with menus and start displaying the menus.

Actual Results:  
Menus may be incomplete or no displayed at all.


1. Effects enabled: slide, desktop grid, present windows, outline, shadows from QtCurve. VSync enabled, direct rendering and OpenGL 2 shaders enabled.
2. Video card as reported by lshw: Mobility Radeon HD 3400 Series [1002:95C4]
1. Partial glxinfo:
glxinfo 
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_EXT_texture_from_pixmap
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV620
OpenGL version string: 2.1 Mesa 8.0
OpenGL shading language version string: 1.20
Comment 1 Alex Dănilă 2012-03-03 11:59:07 UTC
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.
Comment 2 Thomas Lübking 2012-03-03 16:57:17 UTC
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?
Comment 3 Alex Dănilă 2012-03-03 19:27:14 UTC
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
Comment 4 Alessandro Molari 2012-05-24 11:45:18 UTC
I also have this bug.
Switching to XRender fixes the issue, however with OpenGL compositing I get invisible menus.
Comment 5 Thomas Lübking 2012-05-24 12:01:39 UTC
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 ;-)
Comment 6 valdikss 2012-08-19 17:07:16 UTC
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.
Comment 7 valdikss 2012-08-19 17:09:34 UTC
I have KDE 4.9 with intel HD3000 (sandy bridge) and mesa 8.0.4
Comment 8 Thomas Lübking 2012-08-19 18:22:29 UTC
*** Bug 305360 has been marked as a duplicate of this bug. ***
Comment 9 Alex Dănilă 2012-08-19 19:19:10 UTC
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:
Comment 10 valdikss 2012-08-19 19:24:39 UTC
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.
Comment 11 Thomas Lübking 2012-08-19 19:35:18 UTC
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
Comment 12 Adriano Vilela 2012-08-21 18:48:09 UTC
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
Comment 13 Thomas Lübking 2012-08-21 19:09:32 UTC
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.
Comment 14 valdikss 2012-08-22 02:17:33 UTC
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.
Comment 15 Adriano Vilela 2012-08-22 15:54:03 UTC
@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
Comment 16 valdikss 2012-08-22 16:09:24 UTC
(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.
Comment 17 Adriano Vilela 2012-08-22 16:40:48 UTC
In my case, simply enabling the fade effect seems to have solved the problem. So far so good.
Comment 18 Thomas Lübking 2012-08-22 17:39:34 UTC
(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
Comment 19 valdikss 2012-08-22 19:03:01 UTC
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.
Comment 20 Thomas Lübking 2012-08-22 19:09:40 UTC
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.
Comment 21 valdikss 2012-08-22 19:18:01 UTC
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.
Comment 22 valdikss 2012-08-22 19:35:46 UTC
Seems like enabling "Taskbar thumbnails" fixes this issue for me in opera.
Comment 23 Thomas Lübking 2012-08-23 10:53:56 UTC
*** Bug 305656 has been marked as a duplicate of this bug. ***
Comment 24 Thomas Lübking 2012-08-24 21:10:07 UTC
Ideally someone else would test the patch as well.

https://git.reviewboard.kde.org/r/106173/
Comment 25 Christoph Feck 2012-08-26 18:50:42 UTC
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?
Comment 26 Thomas Lübking 2012-08-26 19:43:11 UTC
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.
Comment 27 Thomas Lübking 2012-08-28 19:49:47 UTC
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
Comment 28 Thomas Lübking 2012-08-28 19:51:33 UTC
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
Comment 29 Adriano Vilela 2012-08-29 00:19:19 UTC
@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.
Comment 30 Thomas Lübking 2012-08-29 00:32:39 UTC
could just be that oxygen uses ARGB popups - it will most likely be worked around by that commit, though
Comment 31 Viktor Nagy 2012-08-29 06:16:10 UTC
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.
Comment 32 Thomas Lübking 2012-08-29 07:24:54 UTC
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)
Comment 33 Adriano Vilela 2012-08-29 16:50:27 UTC
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.
Comment 34 Thomas Lübking 2012-09-03 14:06:53 UTC
*** Bug 306195 has been marked as a duplicate of this bug. ***
Comment 35 Thomas Lübking 2012-09-03 14:07:30 UTC
*** Bug 295769 has been marked as a duplicate of this bug. ***
Comment 36 Hugo Pereira Da Costa 2012-09-03 14:11:16 UTC
*** Bug 302961 has been marked as a duplicate of this bug. ***
Comment 37 David Smith 2012-10-14 09:47:38 UTC
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.
Comment 38 Martin Flöser 2012-10-14 09:55:03 UTC
(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.