Startup time for launcher is very slow
|Status:||Closed||Start date:||15 Dec 2014|
|Category:||04 - Applications|
|Severity:||03 - Medium|
I don't know if this is an issue with the launcher itself or the X startup processing. My gut feeling is it has to do with the X startup because it does all that keyboard mapping stuff in desktop.sh.
RM #413: Remove murrine engine from gtkrc. It isn't installed and removing the reference doesn't change the UI but does speed up boot time a bit.
RM #413: Create the fontcache on first boot and save a copy of it so it doesn't have to be rebuilt each time.
#1 Updated by Hammel over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
- Move xmodmap changes out of desktop.sh into /etc/X11/favi.map
- call xmodmap /etc/X11/favi.map in desktop.sh
- Don't copy matchbox files to /root/.matchbox (no longer needed)
- Adjust (down) the usleep() calls in appmgr.
- appmgr could be changed to use signals to run message processing when a new message arrives. The queueProcessor loop would run until there were no more messages on the queue and then wait to be signalled again. That would eliminate the artificial delays (usleep).
#3 Updated by Hammel about 3 years ago
- % Done changed from 10 to 20
Moving the modmap out doesn't change anything. The delay seems to be in launcher itself. Somewhere between the first two of these lines in the log file:
launcher: INFO Application descriptions found: 5 launcher: INFO window w/h: 660 / 578 launcher: INFO Clearing splash
This is where the gtkrc is parsed by the launcher. Parsing the gtkrc is not required on the target (only in testing if you want to see the real UI coloring) so that can be removed.
#5 Updated by Hammel about 3 years ago
Okay, adding timestamps identified the location of the problem in launcher.
[10:28:21] INFO Loaded app: Video Player [10:28:21] INFO Application descriptions found: 5 [10:28:40] INFO window w/h: 660 / 578 [10:28:40] INFO Clearing splash
It's right where I suspected. Now the question is: why? I removed the gtkrc loading. What else is taking so long?
#6 Updated by Hammel about 3 years ago
More logging shows the problem is with this line in launcher:
This is called in order for the next line, selectApp(), to work properly. So, can I get rid of this line and still have selectApp() get called correctly? I may be able to do that with a realize signal on the main window.
#7 Updated by Hammel about 3 years ago
- % Done changed from 20 to 30
There is already an expose event that does this so I removed the gtk_window_show_all() and following selectApp() calls but that fails to display the the app.
So show_all is necessary. There is something happening in the creation of the launcher window/icons that is very slow but only on first boot. This might be loading of the icons from the sd card (verifiable via logging) or it may be a cairo issue.
Note that what I just learned about using an offscreen pixmap for cairo drawing in piclock can be transferred here as well. That may speed things up too.
#8 Updated by Hammel about 3 years ago
- % Done changed from 30 to 50
Found the problem.
The font cache doesn't get built until the gtk app starts. It is created under /var/cache. That directory is volatile so doesn't survive reboots. If I run
that will create /var/cache/fontconfig. If I copy that to /etc/X11/ and then change xinitrc to copy that back to /var/cache then the app starts up almost immediately.The fix is as follows:
- Change firstboot to run fc-cache and copy the fontconfig directory to /etc/X11/ to preserve a copy between boots (/var/cache is volatile).
- Change xinitrc in pmsui to copy /etc/X11/fontconfig to /var/cache.
That should fix that boot up time issue.
#9 Updated by Hammel about 3 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
Made changes to firstboot and xinitrc in the core (buildroot skeleton) to create and use the saved fontconfig directory.
Updated pmsui's xinitrc to copy in the saved fontconfig tree.
Tested on target, committed and pushed upstream.