Bug #413

Startup time for launcher is very slow

Added by Hammel about 3 years ago. Updated almost 3 years ago.

Status:ClosedStart date:15 Dec 2014
Priority:HighDue date:
Assignee:Hammel% Done:

100%

Category:04 - Applications
Target version:0.10.0
Severity:03 - Medium

Description

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.

Associated revisions

Revision b5520998
Added by Hammel almost 3 years ago

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.

Revision d10f50ce
Added by Hammel almost 3 years ago

RM #413: Create the fontcache on first boot and save a copy of it so it doesn't have to be rebuilt each time.

Revision 10c9b478
Added by Hammel almost 3 years ago

RM #413: Copy the saved fontconfig directory to /var/cache.

Revision cda75db4
Added by Hammel almost 3 years ago

RM #413: Add timestamps to log output to aid in performance testing.

Revision 7a681a58
Added by Hammel almost 3 years ago

RM #413: Removed a bunch of unused and unnecessary code. The unnecessary code was essentially duplicate signal callbacks that are not needed under PiBox.

History

#1 Updated by Hammel almost 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
First thing to try:
  1. Move xmodmap changes out of desktop.sh into /etc/X11/favi.map
  2. call xmodmap /etc/X11/favi.map in desktop.sh
Also
  1. Don't copy matchbox files to /root/.matchbox (no longer needed)
  2. Adjust (down) the usleep() calls in appmgr.
    1. 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).

#2 Updated by Hammel almost 3 years ago

Looks like one problem is the use of the murrine engine in gtkrc. It doesn't exist and causes a big delay on bootup (but not on UI restarts).

I've removed that reference from the gtkrc in the pmsui package.

#3 Updated by Hammel almost 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.

#4 Updated by Hammel almost 3 years ago

Changing that had no effect.

I need to put timestamps on the logs for launcher to see where the bottleneck is. Same with appmgr for that matter.

#5 Updated by Hammel almost 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 almost 3 years ago

More logging shows the problem is with this line in launcher:

gtk_widget_show_all(window);

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 almost 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 almost 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

fc-cache -f

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:
  1. Change firstboot to run fc-cache and copy the fontconfig directory to /etc/X11/ to preserve a copy between boots (/var/cache is volatile).
  2. Change xinitrc in pmsui to copy /etc/X11/fontconfig to /var/cache.

That should fix that boot up time issue.

#9 Updated by Hammel almost 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.

Closing issue.

Also available in: Atom PDF