After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768415 - GTK 3.21.3: Corrupted desktop redraws in non-Nautilus file browsers
GTK 3.21.3: Corrupted desktop redraws in non-Nautilus file browsers
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.21.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-07-04 22:41 UTC by Wolfgang Ulbrich
Modified: 2018-02-10 18:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Result of disabling native desktop window when file manager draws background (253.62 KB, image/png)
2016-08-02 19:54 UTC, lukefromdc
Details

Description Wolfgang Ulbrich 2016-07-04 22:41:53 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.
Comment 1 Emmanuele Bassi (:ebassi) 2016-08-02 12:34:50 UTC
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.
Comment 3 Wolfgang Ulbrich 2016-08-02 15:49:45 UTC
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.
Comment 4 lukefromdc 2016-08-02 19:34:31 UTC
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
Comment 5 lukefromdc 2016-08-02 19:54:53 UTC
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)
Comment 6 Matthias Clasen 2018-02-10 05:20:13 UTC
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.
Comment 7 Wolfgang Ulbrich 2018-02-10 08:33:23 UTC
It is fixed.
Comment 8 Emmanuele Bassi (:ebassi) 2018-02-10 18:42:09 UTC
As per comment 7; thanks for your patience!