I'm not sure if this can be helped. At the end of the login process, the Autostart apps get launched. At this point, panel and desktop are already running. But they are actually not usable until the Autostart stuff is completely started, no clicks are possible, not desktop right-click, the panel does not autohide. So xfce is actually not usabel during that time. In my case Autostart contains some bigger applications like email client, calendar app, ..., so it takes some time to start them. As a said, I don't know if there can be done anything about it, but I have the strong impression, that this was not so in earlier versions. The panel and desktop responded slower, of course, but at least they were usable. I have almost the latest CVS versions of xfce4-panel and xfdesktop installed (one or two days old).
I don't think it's related to the autostart process, but rather to the std menu loading, freezing the panel and desktop (you have the menu launcher in the panel, don't you?) Cheers, Olivier.
Correct. Removing the xfce menu from the panel solves the issue for the panel, but not for the desktop. So this is obviously related to the desktop menu. I personally don't need the menu in the panel, but some other users I maintain computers for (since it's more kde/windows like ;-)
i use the desktop menu and the panel plugin but without auto-generated menu and it works fine
yeah, it's the autogenerated menu that causes the slowdown. i'm in the process of making the panel gthread-safe. after that's done, i'll have the menu generate itself in a separate thread.
update: the panel is not going to be multithreaded for xfce 4.2.x, so there isn't much that i can do at this point. i'm hesitant to do periodic processing of gtk events during menu generation, as i've heard that this can cause infinite loops in some situations (i need to look into this). what i _can_ do is make xfdesktop multithreaded and have the menu module use threads if they are available. i'll look into this, but it's very possible this won't happen for 4.2.x, as i'm very afraid of how long it might take to get this stable. edited on: 08-19 17:55
suspending until 4.4.
dum-de-dum, sorry for the spam. reopening bug and setting target milestone to xfce-4.3. presumably we'll be integrating some form of benedikt's new menu system, which should be faster and somewhat non-blocking.
Quick update: the new panel in SVN (4.3.22) does not suffer from this problem anymore, since the menu plugin runs in a separate process. However, the problem is still present in xfdesktop. I haven't really decided what to do yet, and it's looking like Benny's menu might not be implemented in xfdesktop for 4.4. So... blah.
I was bored, so I modified XfceAppMenuItem so it loads the menu icon "lazily". The icon load time seems to be the largest bottleneck during menu creation (at least that's what sysprof says). There's a *slight* delay when showing the menu now, but it's not too bad since it only loads the icons for the particular part of the menu that's shown. Anyway, seems to decrease xfdesktop startup time quite a bit.
This shouldn't be so much of an issue anymore, and it's not going to improve until we get a new menu system for 4.6.