GNOME Bugzilla – Bug 768415
GTK 3.21.3: Corrupted desktop redraws in non-Nautilus file browsers
Last modified: 2018-02-10 18:42:09 UTC
Since commit https://git.gnome.org/browse/gtk+/commit/?id=2c7b21718f18ab743cd79784ae28cad582f58503 which came out on the 9th of June, neither Caja built with GTK 3 nor Nemo has been able to redraw the desktop background when an icon is moved. The old icon position continues to show but becomes effectively part of the background, the icon responds from its new position as expected. Also all shadows and other partially transparent elements get repeatedly rerendered on redraw until they are opaque. This suggests that the background is somehow picking up the foreground, or that the foreground can be drawn but not erased. In the case of Caja restarting the settings daemon clears this, but it starts again the first time the desktop is clicked or anything else done to trigger a redraw. You can watch shadows or other partially transparent elements progressively darken with each click on the desktop when executing this test, showing that the redraws are on top of rather than replacing the former rendering. Also any attempt to change the background fails. Nautilus works OK and can properly render and redraw icons on the desktop as far back as Nautilus 3.8, the oldest version I was able to build against GTK 3.21 and current Debian Unstable. Nemo was forked from Nautilus 3.4 and fails to redraw the desktop properly. Thus something that changed in Nautilus between 3.4 and 3.8 is a requirement for GTK 3.21.3 to handle the desktop but I have no idea what it is. Either a fix for GTK 3.21 or some pointers based on how Nautilus made this work are needed. Using a transparent desktop showing the desktop as rendered by the settings daemon is not the fix, as Nemo does this and still has problems. It's not the double buffering issue for Firefox, I build from master and that fix had no effect on the desktop issue. Caja needs to be able to draw the desktop background itself without relying on compositing, as many users find the marco window manager performs better without it. Note, this is a forward message from one of our MATE devs which can't connect to gnome bugzilla for security reasons. I'm using fedora, but rawhide isn't updated, so i didn't run in this issue yet. But as MATE is switched to gtk3 in rawhide i expect this desktop breakage when rawhide is updated. If you need more infos please ask.
I'm unable to debug this, as I don't know the Nautilus code base very well. It would be possible to check the diff of Nautilus between 3.4 and 3.8 — I suspect it's not going to be huge, if you eliminate the translations and concentrate on the canvas and/or desktop drawing. My suspicion is that Nautilus 3.4 is expecting to handle expose events on the desktop window, whereas that is not necessary. Alternatively, Nautilus is trying to draw on a native window with double buffering. > Note, this is a forward message from one of our MATE devs which can't connect to > gnome bugzilla for security reasons. Bugzilla can be used with a throwaway email account, and you can remove cookies after every session. If people experiencing bugs on old forked code bases cannot help in debugging then I'm not entirely sure what GTK developers are expected to be able to do.
Possibly relevant commits: https://git.gnome.org/browse/nautilus/commit/?id=f0f36c876e4810b190a82e3a953d9263c106447f https://git.gnome.org/browse/nautilus/commit/?id=07d2ca86237fac8b5bddc4e619e43dfc813bc5e7 https://git.gnome.org/browse/nautilus/commit/?id=6d6bf1e7c6049b4bd300ae1d90833a8b5fcf30c4
Thanks, for the infos. We found already the related commits and Luke did a PR for them. https://github.com/mate-desktop/caja/pull/602 But using a transparent RGBA window works only with a compositor. Our window-manager marco support currently compositor and a non compositor mode, same as metacity. W/o compositor the desktop is black. Btw, as far as i know nautilus is also affected if using them outside gnome-shell, eg. flashback session. Personal i would drop the non-compositor mode, but i'm pretty sure that a lot of ppl are not happy with it, as they use Mate on slow and old i386 boxes. I hope i can persuade Luke to answer here as he knows more about the issue than me, i don't know his personal situation why he don't want connect here from the states.
I finally managed to get on with a new account from another email address, on a dedicated session with referrer headers enabled temporarily. Hope I can get on again next time.. The commit in Nautilus made so many years ago that makes the desktop work is this one: https://git.gnome.org/browse/nautilus/commit/?id=6d6bf1e7c6049b4bd300ae1d90833a8b5fcf30c4 But doing this in Caja with the old background code has almost the opposite effect. Not only do icons not get properly redrawn (no "erase" possible) but any windows open when the file manager starts get added to the background too! Disabling double buffering in the same place has exactly no effect. When a transparent desktop window is used and the settings daemon renders the background this code works. I've used it in Nemo sucessfully and also ported over the Nautilus work to use a transparent desktop window and that makes it work in Caja. Both of the other two commits concern this, all traces of the old background handling have to be removed for this to work. The problem is that many users of MATE on older machines get better performance without compositing. When compositing is not used a transparent desktop comes up black as there is no alpha channel. I was able to set a fallback color or graient for this using GTK itself, but never a background-image, which the GTK widgets in question (box and scrolledwindow) just ignored. Had they accepted the image, that would have been my new background setting code. The offending code in GTK itself is behind a "case GDK_EXPOSE:" switch in gtkmain.c and reverting just that part of https://git.gnome.org/browse/gtk+/commit/?id=2c7b21718f18ab743cd79784ae28cad582f58503 will create a "frankenGTK" that will permit the old file manager code to be used and properly draw the desktop
Created attachment 332595 [details] Result of disabling native desktop window when file manager draws background This is what happened when I tried applying https://git.gnome.org/browse/nautilus/commit/?id=6d6bf1e7c6049b4bd300ae1d90833a8b5fcf30c4 when the desktop canvas is from Caja, a file manager that normally draws its own background. Same commit in Nemo, Nautilus, or my Caja branch with a transparent desktop works but this won't support users who lose performance when enabling compositing in Marco (fork of metacity)
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
It is fixed.
As per comment 7; thanks for your patience!