Created attachment 61803 [details] Screenshot of the problem Version: 4.0 (using Devel) OS: Linux When I have compositing enabled on KDE 4.7, an area around both menus and tooltips in firefox is corrupted. It shows a large, repeated pattern of distorted images (see attachment for an example). This only happens when the oxygen-gtk theme is enabled, it doesn't happen for any other theme. Reproducible: Always Steps to Reproduce: 1. Enable desktop effects 2. Enable the oxygen-gtk theme 3. Open firefox 4. Click on a menu 5. Hover your mouse over a tab Actual Results: Area around menu and tooltip is corrupted Expected Results: Area around menu and tooltip appears normal This occurs on both NVidia and ATI graphics cards. Disabling direct rendering, openGL 2, or vsync does not fix it. Disabling translucency, blur, or highlight window does not effect it. There is no longer a listing for the shadow effect, so I could not disable that to test it, nor could I enable the BeShadowed effect (it won't let me). Changing the firefox theme did not fix it. Disabling compositing does fix it.
Re-assigning to kwin (cause this is a kwin issue). I "think" it is a duplicate of an existing bug, and that it has been fixed. To be confirmed by Martin/Thomas
should be fixed with c1ac45e1eb14d584f1f2d1ec2c39a19b2ca1325e @hugo: please remember to change the assignee or we won't get emails.
Isn't the fix is in RC2? The bug reporter is using openSUSE 4.7rc2 packages and also says it happens with ATI cards too.
I don't see any information about the version (using Devel is not saying anything useful). Apart from that I don't know whether this is in RC2 or not, I only know that the fix is in 4.7 branch.
I checked and the fix is in KDE 4.7 RC2 indeed. Todd, can you confirm that you run 4.7 RC2? kwin --version here says Qt: 4.7.3 KDE Development Platform: 4.6.95 (4.7 RC2) "release 1" KWin: 4.6.95 (4.7 RC2) "release 1"
I am using "Using KDE Development Platform 4.6.95 (4.7 RC2) 'release 1'". Sorry, I thought I put that in. I just checked again and the problem still persists. I checked and all of my KDE packages have that version (besides a couple translation files that aren't being used right now).
Here is the exact version for kwin: Qt: 4.7.3 KDE Development Platform: 4.6.95 (4.7 RC2) "release 1" KWin: 4.6.95 (4.7 RC2) "release 1"
a regression was spotted and should be fixed with 55986b32de9e5f5f66ac0c3448b26863cfc2dee0
I'm not sure that that fixed this (but may be implicitly) a) Seems to affect Firefox only (are other Qt or "GTK2" -FF is not really one- applications affected?) b) The bug was initially reported _before_ the patch with the regression fixed by that commit was even pushed (Tue, 12 Jul 2011 18:52:03 +0000 (20:52 +0200)) c) I cannot find 4.6.95 (4.7 RC2) "release 1" on projects.kde.org but it was apparently tagged July 5th - looong before the regression was pushed. d) the regression was about ghost windows on Deleted but the scrot shows pixel garbage (uninitialized pixmap?) around a present (!) tooltip.
I checked some more programs. Amongst ones I tried, no others were affected: GTK: gimp, inkscape, g3data Qt: eric, scribus, Q7Z Other: LibreOffice And yes, the problem is pixel garbage (sometimes matching icons from the program, which would be compatible with pixmaps).
Ok, I guess this is a conflict between oxygen-gtk and XUL then. Do you use FF layer acceleration? (this does also affect the UI which is actually XUL...) about:config, filter for "accel" or "layer"
@Todd: which version of firefox are you using ?
Changing layers.acceleration.disabled from false (default) to true does not change anything. I am using Firefox 5.0
@Thomas I'm not sure I understand how this is a conflict between oxygen-gtk and XUL ... Only thing oxygen-gtk does is create 8 X11 Pixmaps, and pass them, via X properties to the Menu WinID. Can you ellaborate ? Do you think the X11 pixmap is corrupted *at its creation* because of XUL ? Or that the X property is corrupted ? Or what ? Thanks in advance for clarifying. (also: I am also running Firefox 5.0 here, with oxygen-gtk-1.1.1, and intel Graphics Card, and have no problem. What do I miss ?) Hugo PS: re-oppening the bug, as UNCONFIRMED. Feel free to re-assign to oxygen if you feel like it, though I'm pretty clueless on how to fix)
I had thought the OpenGL acceleration (in FF) might "somehow" have freaked the Pixmap format. If the the Pixmap on the server pointed by the prop was invalid we'd just get an X error (invalid pixmap) - the Pixmap must either have been "freed" w/o removing it from the server or your paint instructions were redirected/converted into the void -> pixmap's junk in memory. Since the acceleration is (iirc) only activated for nvidia systems, that might have caused it, but for Todds reply... sigh :-( I'm gonna install a git version of oxygen-gtk and have a look. @Todd: do you use an nvidia GPU?
Nope, no issues here at all. (but force-enabled causes black windows, that's a FF "regression" between 4 & 5. My GPU is probably too old :'( Last guess: @Todd, please try "firefox -safe-mode"
The problem is still present when running firefox in safe mode. The problem is present on two different computers, one running an NVidia GPU and another running an ATI GPU. So it is not NVidia-specific.
pixmaps being freed to early, might be a possibility (though unlikely). I'll look into it ...
Any news on this?
I'm not seeing it in 4.7 final.
I can see these artifacts with kwin 4.7.0, Firefox 5.0, and oxygen-gtk 1.1.50
not being able to reproduce on neither intel nor nvidia here, (with kde and all the rest from trunk) makes it very hard to fix :( Double checking, pixmaps can't be freed too early in oxygen's code. (they're basically freed when oxygen-gtk lib is unloaded). So, no clue.
This is probably a driver and/or a kwin issue then. With NVidia, firefox is ok - with intel graphics the corruption appears.
Just want to add my experience to this bug. Lately a lot of things have changed in my system: KDE 4.7 installed from openSUSE repos. openSUSE recently released some security updates (kernel patch among others) I upgraded NVIDIA driver from 275.21 to 280.13 Before these changes menus where just fine in Firefox but after changes they are corrupted. On my system the only change that fixes the problem is downgrading oxygen-gtk 1.1.1 that is included with the 4.7 repos to 1.0.5 that is in the 4.6 release repos for openSUSE). Downgrading NVIDIA driver does not help.
Git commit c6e3de7cce4c4c5879b7dfa758c314d203a698b6 by Hugo Pereira Da Costa. Committed on 08/08/2011 at 11:45. Pushed by hpereiradacosta into branch 'master'. Added debug info for shadow pixmaps. CCBUG: 277613 M +26 -0 src/oxygenshadowhelper.cpp http://commits.kde.org/oxygen-gtk/c6e3de7cce4c4c5879b7dfa758c314d203a698b6
For people having the problem and willing to help understand the issue, I added more debug messages to oxygen-gtk. Could someone - get oxygen-gtk from 'master' (it is safe: the code is stable) - compile it in "debug" mode (that is: cmake -DOXYGEN_DEBUG=1) - run firefox (or thunderbird) with it, redirecting the log into a file (that is: firefox >& log) - try open a (corrupted) menu, and close - post the resulting log file here (as attachment) Thx !
Created attachment 62660 [details] Logfile opening Tools menu
Sure, Hope that log file above can help! Best regards, Tobias
@Tobias: Helps a lot ! "IA__gdk_x11_visual_get_xvisual (...)" That's the bad guy, most likely (message appears 16 times, which is the number of shadow pixmaps we create. So very good candidate, and I don't have it here). Now, well, I cannot find the debug info I added to oxygen-gtk with the commit from #25. Did you first update the oxygen-gtk code ? (git pull) ? If not, could you give it another shot ? Lines that should appear are such as: Oxygen::ShadowHelper::reset Oxygen::ShadowHelper::initialize Oxygen::ShadowHelper::createPixmapHandles In the meanwhile I'll investigate the origin of the above. Will keep you posted. Hugo
Created attachment 62664 [details] New logfile
Sorry, Thought I got the updates (didn't have the code at all so I downloaded a tarball and ran initrepo.sh). Anyway, attached is a new file which should contain the new messages.
Thanks ! I should submit a patch (that checks the guilty missing Visual) soon (few minutes). It may (or may not) result in having no shadows for firefox and company (because I do not know the origin of this visual being NULL), but at least - no more corruption - correct shadows for other gtk apps. Will keep you posted.
Git commit 1e0dc79cb39134ecdf22bead31c78cd40c242fa2 by Hugo Pereira Da Costa. Committed on 08/08/2011 at 15:38. Pushed by hpereiradacosta into branch 'master'. Added checks on Screen, Display, and Visual before allocating the pixmaps needed for shadows. CCBUG: 277613 M +43 -2 src/oxygenshadowhelper.cpp http://commits.kde.org/oxygen-gtk/1e0dc79cb39134ecdf22bead31c78cd40c242fa2
Ok. Comment #33 should "fix" the issue. Please report back - whether corruption is gone as expected - whether you do have shadows for menus or not. (if not, its still an issue, but at least a less annoying one).
Git commit b150eee18b853d889aa0c8556762fac4833dfa5b by Hugo Pereira Da Costa. Committed on 08/08/2011 at 11:45. Pushed by hpereiradacosta into branch '1.1'. Added debug info for shadow pixmaps. CCBUG: 277613 M +26 -0 src/oxygenshadowhelper.cpp http://commits.kde.org/oxygen-gtk/b150eee18b853d889aa0c8556762fac4833dfa5b
Git commit e9f836bf20edbf45926f13fa681400d56e4275d9 by Hugo Pereira Da Costa. Committed on 08/08/2011 at 15:38. Pushed by hpereiradacosta into branch '1.1'. Added checks on Screen, Display, and Visual before allocating the pixmaps needed for shadows. CCBUG: 277613 M +43 -2 src/oxygenshadowhelper.cpp http://commits.kde.org/oxygen-gtk/e9f836bf20edbf45926f13fa681400d56e4275d9
Corruption gone with the patches, unfortunately the shadows as well (but for me that's a minor issue). Thanks for quick support!
I believe the shadows being gone could be due to some "optimization" on the firefox side. Hopefully, kwin might provide some "default" shadow when none is installed (as here) in the near future, which would "fix" the issue (it would not have the problem that oxygen-gtk has). Unless some kwin dev (Thomas ?) has any clue why I cannot have access to the Argb Visual via gtk inside firefox (XUL) and if he knows a way to circumvent it ? (mmm. Maybe I could try some X calls directly, since the guy is used for creating native X11 pixmaps). Still, closing.
Hummm? gdk ranks screen over display?? Well, I saw Episode VI before Episode I, so... ;-) Anyway, i guess FF will either setenv("XLIB_SKIP_ARGB_VISUALS", 1); what you could test via getenv() or there might be a clash with FFs OpenGL capabilities. See bug #262064 and check the window for a RGB_DEFAULT_MAP property. Otherwise I've presently no other ideas at hand, sorry in case.
*** Bug 279761 has been marked as a duplicate of this bug. ***
Hello all, I recently came across this problem, pixel garbage around tooltips and all GTK+ applications menus. No theme change made a change nor did disabling desktop effects. I tried all sorts of things but decided to upgrade the GTK+:2 version from: gtk+-2.24.10-r1 >> gtk+-2.24.13-r1 This solved the problem or seems to have. My distro had the above versions masked by keyword as i use gentoo. For those not familiar with Gentoo the keyword masks protect the package manager from compiling packages that wont work on a spacific archetectures. e.g. X86 vs ARM or amd64 etc. I guess there is an issue with newer packages that use the GTK:2 engine working with the older gtk+ version. (a small gentoo portage glitch maybe) Unmasking by keyword fixed it for me anyway so if anyone else runs into the problem they can check there versions of the file. Hope it helps someone.