| Summary: | bugs in GTK Applications menu with kwin | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Raphael Cazenave <rcleveque> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 4.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| URL: | http://www.youtube.com/watch?v=-Z4IMuxYRpw&feature=youtu.be | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Raphael Cazenave
2012-08-17 22:55:38 UTC
we stay in touch for any information. Kind regards Firefox is not a gtk+ application (but XUL)
Can you
a) check whether it happens with ARGB visibles disabled
XLIB_SKIP_ARGB_VISUALS=1 gimp
if yes,
b) provide a screenshot
in any case better attach a dump of "xprop -root > root.props" and "xprop > client.props" (after the second command click an affected gtk+ window - you'll unlikely be able to click a popup menu this way)
please also attach output of qdbus org.kde.kwin /KWin supportInformation are these GTK 2 or GTK 3 application. Firefox I know to be GTK 2, but what about the others? Hey, with XLIB_SKIP_ARGB_VISUALS=1 gimp , the problem is less frequent, but sometime (1 time for 15 times) when i click on menu, nothing happens. Screenshot : http://funkyimg.com/u2/2007/782/865823gimp-screenshot.png dump of "xprop -root > root.props" : http://paste.debian.net/184447/ output of "xprop > client.props" after clicking on a windows launched with "$ gimp" : http://paste.debian.net/184452/ Kind regards I try pidgin too, same issue. Gnumeric, same issue. i try again to change the gtk theme with "$ gtk-theme-switch2" but with all themes there is the issue Kind regards here is my "qdbus org.kde.kwin /KWin supportInformation" http://paste.kde.org/536522/ kind regards The only issue i can perceive on on the screenshot is that a localized string takes too much space yet is painted "outside" the menu, what -since ARGB visuals are disabled- means that the menu window is actually wider than the frame suggests (that is an issue of gtk+ or the theme engine) Can you please also provide a shot of the original issue (ie. with ARGB visuals enabled, just don't set that variable) The xprops do at first sight not contain anything suspicious. it's the fglrx - that might be important. Could you please try whether enforcing direct rendering improves the situation. Please run KWIN_DIRECT_GL=1 kwin --replace & from a command line in case you have the latest driver. If not please update the driver My first thought, but OP says
> composite : openGL OR Xrender, its the same
@rcleveque
shot in the dark: enable the fade effect
Thanks for your help. Thomas Lübking 2012-08-18 18:04:19 UTC: Here is a shot of original issue with "$ XLIB_SKIP_ARGB_VISUALS=0 gimp" : http://funkyimg.com/u2/2007/939/888942XLIB_SKIP_ARGB_VISUALS_0_gimp.png and with "$ gimp" : http://funkyimg.com/u2/2007/949/941294gimpONLY.png Martin Gräßlin 2012-08-18 18:15:27 UTC : when i try KWIN_DIRECT_GL=1 kwin --replace & , the problem still exist. Kind regards Thanks. I bet your right arm that activating the fade effect will prevent this. Likely some issue with damage events (I wonder whether those popups support the XSYNC extension) @Martin we could probably schedule readyForPainting() and corresponding signals for a few (like 50) ms for all windows that don't use XSYNC from either side. E17 does that for sure - no idea about compiz/mutter that sounds like a reasonable solution to me Hey, Thanks for your help, youre right, with fade effect, its ok :) I keep it enabled. Kind regards. *** This bug has been marked as a duplicate of bug 295254 *** |
