GNOME Bugzilla – Bug 734996
Desktop background briefly missing after each log-in on slower computers
Last modified: 2020-07-22 01:57:59 UTC
I thought this bug already existed, but I can't find it anywhere... When starting GNOME Shell on a fast computer, the desktop background appears right away. When starting GNOME Shell on a slower computer (but not too slow, it's an Ivy Bridge i3!) the desktop background is instead pure blue for about 0.5-1.5 seconds, which is extremely noticeable after each log-in. I believe this bug was introduced in one of the 3.8.x point releases (maybe [1]?), and perhaps hasn't gotten the attention it deserves because it's not noticeable if you have a nice computer. [1] https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-8&id=1020d8a0f8523a04d8336b1348388b8b242e414f
I guess I should mention the expected behavior: the transition from gdm to gnome-shell should not begin until after the desktop background has been completely loaded.
I've posted a $150 bounty for whomever fixes this bug. The money was originally from Adam Dingle; thanks Adam! https://www.bountysource.com/issues/4249619-desktop-background-briefly-missing-after-each-log-in-on-slower-computers
And if you don't have a low- or mid-range computer lying around to test this on: I was able to reproduce this in a VM on my fast computer.
Michael, can you check whether this problem still happens with 3.14.1?
Yes, this is still broken and very highly-noticeable.
Hello, I performed some testing, and it seems this issue is no longer present on 3.16. Could this issue be closed on this information, or would further analysis be required? Is 3.14 still maintained? Thanks, Vittorio
This issue is definitely still present in 3.20. :(
(In reply to Michael Catanzaro from comment #2) > I've posted a $150 bounty for whomever fixes this bug. The money was > originally from Adam Dingle; thanks Adam! > > https://www.bountysource.com/issues/4249619-desktop-background-briefly- > missing-after-each-log-in-on-slower-computers Hmmmm, this bounty is still open, and I can't figure out how to withdraw the money from Bountysource, so it's a loss to our community if nobody claims it. All you have to do, once you're able to reproduce the bug, is delay the log in operation until after the desktop wallpaper has loaded. Note: (In reply to Michael Catanzaro from comment #3) > And if you don't have a low- or mid-range computer lying around to test this > on: I was able to reproduce this in a VM on my fast computer.
Hello, I had invested quite a bit of time (too much) to reproducing the bug. I set up a virtual machine that would auto-login on gnome. The hypervisor would record video output to a file. I then created a script to extract individual frames from the video file. I then scanned each frame for the color blue, which would otherwise not be present. With this test set-up, I was able to reproduce the issue 1 in every 10 times more or less. Unfortunately, for me, this was not reliable enough to try to attempt software modifications, because it means having to test each software modification at least 20 lifecycles in order to have the confidence the issue was improved. I would like to "give it another go", but it would be very useful to have a more "reproducible" test-case. I would appreciate any input here. (After your input, I verified that the issue exists at least up to 3.22.), however I believe it was way more frequent around 3.14. Thank you, Vittorio
If you have access to a non-SSD hard drive, try testing with GNOME installed on that. I don't see this problem myself anymore because I switched to SSD, but it was quite obvious and ugly back when I used a rotational disk.
Alternatively, you can investigate the code and see if there is a way to arbitrarily slow down the I/O operation that loads the desktop background from disk. It should be possible by using Timeout.add_seconds to add, say, a five-second timeout before loading the background. Then you should see GNOME log in to a solid blue background, and then the wallpaper will load five seconds later. The bug would be fixed when, with that modification, GNOME does not log in immediately, but instead stalls for five seconds.
This somehow regressed again in 3.34, now I see this bug on my machine with an NVME hard drive. Previously I could only reproduce when using an old rotational disk. I still have a $150 bounty on this issue, btw, if any students are interested. (Bountysource won't let me withdraw the bounty.)
Hi there, I'm potentially interested in this. As I understand this, you would rather like a reduced productivity (having to wait longer on login) than to have a visual 'glitch'? So, I'm not experienced in working with gnome software. Maybe you can give me hints. The solution would need to be in gnome-shell as well as in gdm. And it must be backwards-compatible. gnome-shell must be startable from older gdm and other display managers without difference, and gdm should know whether it is starting an older gnome-shell or a gnome-shell that will tell it, when it is finished loading the background. Correct?
(In reply to 3ter.von from comment #13) > Hi there, I'm potentially interested in this. Awesome. > As I understand this, you would rather like a reduced productivity (having > to wait longer on login) than to have a visual 'glitch'? Right. We shouldn't display anything before the desktop background is loaded. It might cause login to take a few milliseconds longer, but that's no problem. > So, I'm not experienced in working with gnome software. Maybe you can give > me hints. > > The solution would need to be in gnome-shell as well as in gdm. I might be wrong, but I don't think it would require any changes in gdm. > And it must > be backwards-compatible. gnome-shell must be startable from older gdm and > other display managers without difference, and gdm should know whether it is > starting an older gnome-shell or a gnome-shell that will tell it, when it is > finished loading the background. Correct? Nah. If this change is entirely internal to gnome-shell, as I suspect, you won't have to worry about backwards-compatibility at all. And if, for some reason, we do require changes in gdm (I doubt it), then it's fine to require that both gdm and gnome-shell be upgraded in sync. I haven't investigated this very far myself, but maybe a good place to start would be the comment at the top of js/ui/background.js. I also see _prepareStartupAnimation() in js/ui/layout.js. Currently that calls _updateBackgrounds(), which calls _createBackgroundManager() for each monitor, which asynchronously loads the background image. When starting the shell for the first time, we want that to be sync instead of async. *But we want to preserve the current async behavior when not starting the shell, because we don't want gnome-shell to hang (even for a very short time) when updating backgrounds, except during startup.* So perhaps we want to have a second version of _updateBackgrounds() that actually waits for the backgrounds to be updated instead of just starting the process of updating the backgrounds, or give it a parameter to choose between the two behaviors. Regardless, it will require changes in background.js. Note: I'm not a gnome-shell developer.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1368
MR is landed. I haven't closed a Bugzilla bug in such a long time. I miss the old canned replies: This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.