[patch] Preload popup menus for the desktop (3.5)

Michael Dean miketdean at gmail.com
Thu Mar 30 20:05:35 BST 2006

On Wed March 29, 2006 19:35, Scott Wheeler wrote:
> Here's one that will no doubt be at least semi-controversial, but for me I
> believe solves a significant issue for first impressions in KDE.
> The right menu button on the desktop is slow.  Really slow.  In my
> profiling here (on a fast machine) it took between 250 - 750 ms to pop up. 
> Waiting 3/4 of a second for a RMB menu on a text file just seems silly.
> The same issue applies in Konqueror and if this is accepted I'll probably
> address it there too.
> The basics of what this does are:
> - Use a QCache to store up to 50 menus in memory
> - Create the menu as soon as the user is over the item with the mouse
> - When the RMB is pressed, check the cache first for the menu
> Of course in some cases, if the user very quickly uses the RMB button on an
> item that they've never hovered over before there can still be a delay, but
> in practice there's usually a short delay before the right mouse button is
> pressed and in the course of a desktop session most of the time menus are
> reused (i.e. trash, home, etc.)
> This makes the desktop feel much more responsive in general, and I'd like
> permission to commit it to 3.5.
> -Scott

I for one like this idea, though I would make:

+#define MAX_POPUP_MENUS 50

user configurable instead.  Optimizing away the reason it's slow is of course 
an ideal solution, but this may still help significantly on some slow 
machines.  On my laptop, this would be a much appreciated improvement.  On my 
dualcore Athlon64, however, I might not want to have any menus cached as it 
renders them very quickly.  Being able to tune this would be a boon.

Also, there should be some ability to set priorities on menus in the cache: 
Always cache, cache if possible, and cache if space is available.  The most 
commonly used menus should always be cached, of course.  If you wanted to 
really enhance this capability, counters could be used to determine a 
preferencing order.

Just my two cents,

More information about the kde-core-devel mailing list