Project

General

Profile

Actions
Copy link

Bug #413

closed

Startup time for launcher is very slow

Added by Hammel about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
High
Assignee:
Hammel
Category:
04 - Applications
Target version:
0.10.0
Start date:
15 Dec 2014
Due date:
% Done:

100%

Estimated time:
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.

Actions
Copy link
 #1

Updated by Hammel about 10 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).
Actions
Copy link
 #2

Updated by Hammel about 10 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.

Actions
Copy link
 #3

Updated by Hammel about 10 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.

Actions
Copy link
 #4

Updated by Hammel about 10 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.

Actions
Copy link
 #5

Updated by Hammel about 10 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?

Actions
Copy link
 #6

Updated by Hammel about 10 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.

Actions
Copy link
 #7

Updated by Hammel about 10 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.

Actions
Copy link
 #8

Updated by Hammel about 10 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.

Actions
Copy link
 #9

Updated by Hammel about 10 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.

Actions
Copy link

Also available in: Atom PDF