When I right-click on the desktop, it takes some time (200ms) before the context menu appears. For comparison, the Applications Menu in the panel opens with no noticeable delay. I'm using Xfce 4.10 with Xfdesktop 4.9.3. I'm not sure, but I suspect that the Application submenu is taking a long time. Maybe it could be preloaded somehow?
Do you have an messages from xfdesktop in your ~/.xsession-errors ?
I noticed the same behavior. I could get rid of the delay by deselecting "show applications menu on desktop right click". If that delay is caused by building the applications menu up, maybe the menu could be made earlier (for example from an idle timer) and stored somewhere?
Actually, it is enough to deselect "show application icons in menu" to get a similar result. Another reason for perceived "slowness" is that the RMB menu pops up on button *release* event (not button press). I guess this is done so because the RMB can also be used for DnD, but, IMHO, having a quicker reaction is more important than DnD (we already use LMB for it anyway).
I noticed that when opening the Applications Menu from the panel button, the icons are being loaded on demand; for example, sometimes (e.g. after boot), the submenus show up and only a short time later do the icons appear. However, I've never seen this behaviour in the menu when opened by right-clicking the desktop. I suspect that there is an option for on-demand loading that isn't enabled in the desktop case?
That is because the XfcePanelImage has a lazy image loader.
I think Ambroz's point was that this lazy loading doesn't work(?) when applications menu is open with a right click. Hence the slow response to the mouse click.
The problem is in garcon. It has to scan an monitor a lot of files, the first time this is done it will take a bit of time (depending on the number of files/folders, but 100/200ms is 'normal'). Once this is complete for xfce4-panel or xfdesktop (files are in memory cache) it is fast (or the complete GtkMenu is cached inside the application). Only way to speed this up is to idle pre-load the menu no startup. Possibly in a separate thread. We do this on-demand so less is executed on startup, with the downside it takes longer when you first use the application menu. Idle-ing the image loading helps a bit, but since most of the icons are in gtk mmapped-icon-cache also this has an acceptable speed. Menu files (.menus, .directories and .desktop) are scattered around this disk.
Once cached, applications menu (launched from the plugin) appears immediately. But the right-clicking on the desktop always gives me ~0.2s delay (from mouse release) so apparently we don't everything we need on rmb click. BTW, what's your opinion on switching from mouse-release to mouse-press? That adds additional delay, and prevents the user from dragging onto the menu and activating an item by releasing the button (this is supported by most menus in the system, including applications menu plugin).
I think mouse release is better.
Created attachment 4397 Improve menu icon loading This code checks if the icon theme has the custom icon name and loads that directly into a gtk_image widget rather than a pixbuf first, which should provide a small speed improvement when many items are present in the menu. Before patch with Icons elapsed: 0.129740 elapsed: 0.143799 elapsed: 0.126939 Before patch without Icons elapsed: 0.010751 elapsed: 0.009460 elapsed: 0.011937 Patch with Icons elapsed: 0.020162 elapsed: 0.013139 elapsed: 0.019224 Patch without Icons elapsed: 0.007701 elapsed: 0.012471 elapsed: 0.011793
This patch does indeed speed it up. Thanks! However, I still think it would be a good idea to open the menu on button-press instead of button-release. Is there some specific reason why dragging needs to work with the right button? It can already be done with the left button, and I'm guessing most users are accustomed to dragging with the left button anyway. And, as Andrzej already mentioned, it breaks the hold-and-release use of the context menu.
It might be worth noting that the right-click behaviors of the applications button and the desktop context menu have been reversed from Xfce 4.8 to 4.10. In 4.8, button worked on release, but menu worked on press; in 4.10, it's exactly the other way :) The applicability of hold-and-release has reversed too of course.
Patch idea is fine, haven't tried it.
Pushed to master, http://git.xfce.org/xfce/xfdesktop/commit/?id=1919aa9d7ee74728815839694ee0d35877f1f725