GNOME Bugzilla – Bug 445946
Main Menu icons should be preloaded
Last modified: 2020-11-06 20:25:04 UTC
Please describe the problem: When opening the menu for the first time, the icons are loaded. This probably saves a small amount of start time for Gnome however it makes things look slower as you need to wait for the icons to load and makes the user wait while they are loaded. Most users will probably be going straight for the menu after they start anyway. Possibly make a way to cache the menu icons to decrease load times. Is is particularly bad on LiveCDs where the delay can be quite long, but its also apparent on faster systems. Steps to reproduce: 1. Start Gnome, particularly on a slower system 2. Open Gnome-Panel 3. Wait Actual results: Icons must be loaded, there is just empty space where they should be and the system takes time to load them. Expected results: Icons already there. Does this happen every time? Yep Other information:
Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/44002 also mention that the menu is slow to open on first try
Confirmed in 2.20.0.1
(In reply to comment #1) > Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/44002 > also mention that the menu is slow to open on first try The guy from your bug complains about the menu being slow when showed the first time. This is about the asynchronous icon loading. Asynchronous icon loading is a feature to make sure the menu is being showed when the items are loaded, not when the images are loaded too. Vincent, this is a feature, not a bug, right?
(In reply to comment #3) > Vincent, this is a feature, not a bug, right? This is a feature, but we should still preload the icons before the menu is opened, so that it feels better.
Regarding the speed of the menu on first use, I can confirm that it is somewhat slow and I never understood why (maybe because I never looked at the code :-)). I mean, my main menu contains 13 submenus/items and my processor is fast enough to create it in a few ms, while it actually takes more or less 1-2 seconds on the first use. Is the menu completely created (recursively *all* submenus/items) on that first use? If so, it might be interesting to use some sort of lazy tree to create submenus/items as needed. Once again, I wan't to state that I didn't look at the code, so please forgive me if you're already using such technique. But if that's the case, then I don't get why it takes so long to create a so small menu.
*** Bug 512265 has been marked as a duplicate of this bug. ***
*** Bug 486130 has been marked as a duplicate of this bug. ***
I have filed a similar bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477509 I would therefore add here the problem that the *whole* X11 interface freezes here during the time the menu bar generates its menu, which is really annoying. That is the main reason while I opened a seperate bug over at Debian.
Could that be related to svg icons that could slow down the menu ? KDE 4 has IconCache for that see http://rivolaks.blogspot.com/2007/09/iconcache-benchmarking-results.html & http://www.nabble.com/rendering-svgs-vs-using-prerendered-images-from-the-icon-cache-td14958263.html & http://www.nabble.com/Ditch-SVGs!-(was-Re%3A-svg-icons-again)-td15203434.html
The problem still happens with gnome-menus-2.22.2-1 (gnome-panel-2.22.2-2, Gnome 2.22.3, Fedora 9). After loging, and with processor at 0%, the first time I click on the Main Menu icon (the foot), it's opened after 4-5 seconds! (the computer is only ~1 year old). It seems to me that all the menu structure (main menu, submenus, icons, ...) is generated after the first click. So I think that some other (smarter) method should be used to save time. Some ideas to fix the problem: - The user wants to see SOMETHING inmediately after the click. - That "something" hasn't to be the final menu. The "something" could be, for example, an empty menu of fixed size (for example, size for 5 items). - Once the empty menu is showed, the names of the items that exist in the the root level can be read. (only the names, an only in the root level). - Once the root item names are known, the names can be inserted into the empty menu, which will be (probably) resized. (only the names are inserted, not the icons) - Once the root item names have been inserted, the icon names (for the root items) can be read from disk. - Then, the icon files can be read from disk. - Then, the icons can be added to the menu. In this way, all the menu generation is done asynchronously. The user gets inmediate response to the click, and can interact with the menu in paralel to its generation. The user hasn't to wait for the termination of the generation, he/she can click on a submenu before the icons are added, or even before the last item names are aded to the list. For the generation of a submenu, the same method can be used: when the user clicks on a submenu, the steps can be exactly the same as when the user click on the main menu foot. I think that this proposal will increase the speed, and so, the usability of the main menu. Please guys, fix the problem as soon as possible. It's frustrating to wait for 4-5 seconds to see something.
Please confirm! This needs to be fixed.
Let me allow to subscribe to this bug by making the hardy useful comment: „I don’t like the current behaviour either and would welcome a faster menu“.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.