GNOME Bugzilla – Bug 671406
Show a progress spinner if loading the overview takes a long time
Last modified: 2015-02-27 02:11:59 UTC
When you first load gnome-shell's overview, the visual give a "broken" feel. No icons or thumbnails are shown and especially when combined with the :active backdrop the view appears broken. Apart from generally making things faster :), I suggest showing a spinner every time a display is not ready. So for the initial load a spinner would appear in the middle of the screen like mocked up here: http://jimmac.fedorapeople.org/gnome3/initial-load.webm This is the worst case scenario when no items have been preloaded. Obviously we could be loading the icons before entering the overview and we don't need to have the whole set of icons loaded to show the overview (only dash items). This is to show the case when the display is never ready. Similar solution applied for populating the search results (mockups to come).
The the bug here is not the lack of the spinner but the fact that things are / can be slow. We should fix that instead of trying to hide them with such tricks.
Of course, but there's always going to be the one machine where disk IO sucks. We're going to have to wait for icons to load asynchronously if we don't block the compositor. We can either show a spinner, or a blank space.
Whatever the solution, we should not be exposing a state that looks broken.
(In reply to comment #2) > Of course, but there's always going to be the one machine where disk IO sucks. Well then we should not do that. (Blocking I/O in the compositor). (In reply to comment #3) > Whatever the solution, we should not be exposing a state that looks broken. No disagreement here, I just prefer to fix the root cause rather then papering over the symptoms ;)
I completely agree: things should be fixed to never block. on the other hand, there are some things that will just block the main thread, and that you cannot offload to separate threads - unless we rethink the way the entire Clutter, Mutter, and Shell work. one example of things that will block is texture upload. you can preload the images into a PBO, and then map it, but it's fair chunk of work, and all it does is simply deferring the actual pixel pushing from system memory to the GPU. we could have two GL contexts, sharing resources, and then load the images from another thread, but I don't know how well a) drivers react to this kind of usage of OpenGL and b) how do Clutter and the Shell interact with that; I've toyed with this idea for a while, but it will require interesting changes in the lower levels of the stack. above all, though, if the goal is never to appear to be blocking, and always inform the user that something - really, *anything* - is happening and that the UI hasn't frozen, then we might just as well bite the bullet, and use spinners *now*, and stop later when everything loads up in a couple of frames.
Changing volume using the media-keys/remote control shows a big speaker-icon on the screen. This icon needs to load from HDD, blocking the actual volume change for up to 3 seconds on my system (spin-up time). I/O should always be done asynchronous in another thread, otherwise the entire user experience that is the Shell will appear to hang. This bug is about improving responsibility in the system, right? 1. The volume change icon should load from HDD asynchronous and appear when it has been loaded, white the actual volume change should be instantaneous. 2. Showing a spinner in the overview is a good thing (it's a sign of asynchronous I/O, which is the real solution to this problem)
(In reply to comment #6) > Changing volume using the media-keys/remote control shows a big speaker-icon on > the screen. This icon needs to load from HDD, blocking the actual volume change > for up to 3 seconds on my system (spin-up time). I/O should always be done > asynchronous in another thread, otherwise the entire user experience that is > the Shell will appear to hang. Except that in this particular case, the shell loads the icon neither synchronously nor asynchronously, but rather not at all :-) Both processing the media key presses and showing the OSD is handled by gnome-settings-daemon.
(In reply to comment #7) > (In reply to comment #6) > > Changing volume using the media-keys/remote control shows a big speaker-icon on > > the screen. This icon needs to load from HDD, blocking the actual volume change > > for up to 3 seconds on my system (spin-up time). I/O should always be done > > asynchronous in another thread, otherwise the entire user experience that is > > the Shell will appear to hang. > > Except that in this particular case, the shell loads the icon neither > synchronously nor asynchronously, but rather not at all :-) > > Both processing the media key presses and showing the OSD is handled by > gnome-settings-daemon. Should I open a new bug then? Because I really experience up to 3 seconds of pure hang while changing volume.
(In reply to comment #8) > > Both processing the media key presses and showing the OSD is handled by > > gnome-settings-daemon. > > Should I open a new bug then? Because I really experience up to 3 seconds of > pure hang while changing volume. you should open a different bug against gnome-settings-daemon, and it most likely has nothing to do with icon loading.
(In reply to comment #4) > Well then we should not do that. (Blocking I/O in the compositor). See also Bug #687364, which is concretely about the blocking that happens when first opening the overview, and Bug #687362, which is a metabug for blocking I/O in the compositor generally. (In reply to comment #5) > always > inform the user that something - really, *anything* - is happening Even if all I/O moves to a secondary thread (and even if the upload to the GPU can move there too), for as long as that thread is busy we're still left with "until all the icons have loaded, we should show *something*" which I think is perhaps the scope of this bug?
Renaming for clarity. As an aside, we should probably only show this if loading takes more than a couple of seconds.
I haven't noticed the delay for a while now. Is this still needed?
Initial load is much improved since 3.12. It's probably still an issue for spinning disks, but perhaps this is becoming an edge case.
(In reply to comment #13) > Initial load is much improved since 3.12. That's mostly due to defer app loading (which was always the slow part) to the first time the app picker is shown rather than doing it when opening the overview. So maybe we need a spinner for the app picker now?
(In reply to comment #14) > (In reply to comment #13) > > Initial load is much improved since 3.12. > > That's mostly due to defer app loading (which was always the slow part) to the > first time the app picker is shown rather than doing it when opening the > overview. So maybe we need a spinner for the app picker now? Yes, but only if it can be slow in some situations.
I think things have improved enough to not require a loading indicator, but feel free to reopen if you disagree.