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 445946 - Main Menu icons should be preloaded
Main Menu icons should be preloaded
Product: gnome-panel
Classification: Other
Component: menu
Other All
: Normal minor
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 486130 512265 (view as bug list)
Depends on:
Reported: 2007-06-10 05:32 UTC by H3g3m0n
Modified: 2020-11-06 20:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18

Description H3g3m0n 2007-06-10 05:32:14 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?

Other information:
Comment 1 Sebastien Bacher 2007-08-09 16:49:22 UTC
Ubuntu bug also mention that the menu is slow to open on first try
Comment 2 Emilio Pozuelo Monfort 2007-10-02 16:14:16 UTC
Confirmed in
Comment 3 Sven Herzberg 2007-10-27 21:17:22 UTC
(In reply to comment #1)
> Ubuntu bug
> 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?
Comment 4 Vincent Untz 2007-10-28 14:48:50 UTC
(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.

Comment 5 F. Ingelrest 2007-10-28 14:50:24 UTC
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.
Comment 6 Vincent Untz 2008-04-12 00:33:17 UTC
*** Bug 512265 has been marked as a duplicate of this bug. ***
Comment 7 Vincent Untz 2008-04-12 00:33:54 UTC
*** Bug 486130 has been marked as a duplicate of this bug. ***
Comment 8 anarcat+releases 2008-04-23 18:18:28 UTC
I have filed a similar bug in the Debian BTS:

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.
Comment 10 a_64 2008-08-23 14:12:59 UTC
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.
Comment 11 Craig Younkins 2008-10-15 20:35:55 UTC
Please confirm! This needs to be fixed.
Comment 12 Joachim Breitner 2010-09-25 07:53:18 UTC
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“.
Comment 13 André Klapper 2020-11-06 20:25:04 UTC is being replaced by 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

Thank you for reporting this issue and we are sorry it could not be fixed.