according to mfinkle, we're spending 500ms in InitLookAndFeel grabbing defaults from gtk. That's all well and good, but we then throw all those defaults out because of the black theming on maemo. To top it off, we trigger the observer each time we set the a pref in js which is wasteful. I propose ifdefing InitLookAndFeel to set hard coded defaults for maemo. Also, gavin points outthat nsXPLookAndFeel gets the pref service on each call (http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsXPLookAndFeel.cpp#310) we should fix that too.

It'd be interesting to see how much this hurts us on WinCE, too.

Currently, Fennec uses it's own colors, supplied via preferences. I have a plan to also use ui.use_native_colors = false (since we supply our own) and then wrap the code that initializes the native colors (the slow part) in a sUseNativeColors block. This plan would allow Fennec to side step the slow initialization, but still allow other xul-based application to use the system colors if they want. Patch coming up. Other ideas welcome too.

This patch implements the previous comment. Using this patch and "ui.use_native_colors" = false in Fennec I see a reduction of ~225ms during startup. The talos startup test (run locally) varies quite a bit, but 5-run averages result in: with patch: 5455ms without patch: 5647ms The path still has the timing code in it too.

what about the other 275ms? is there more win here?

(In reply to comment #4) > what about the other 275ms? is there more win here? nsLookAndFeel::InitLookAndFeel still has about 30ms I didn't remove because it was not color related. The bigger chunk comes from nsLookAndFeel::InitWidget which is also called in the constructor. http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsLookAndFeel.h#83

Stuart - I need a sanity check from you on this. If we want it to land, we need it soon.

stuart - assuming that this still is a startup perf, do you still want this?

This patch seems useful, why isn't it landed?