Seen in http://people.mozilla.com/~bgirard/cleopatra/#report=d9d022b3178b5e8e72e2036cf040b316a5eca471 This time is off the critical path to PBrowser:LoadURL(), which is to say this time is consumed in parallel to the content process. However, since the b2g process is prioritized above content processes, this will be time starved away from the content processes. A plurality of these samples are in a sync reflow forced by a StatusBar.height() getter. We'll need to do the reflow eventually, but forcing it in this way may be creating extra work. It looks really easy to avoid this. A surprising number of these samples are in BrowserElementParent.js code, about 10 samples (~13ms). One of the calls looks like we're unluckily MJ'ing a BEP method. Maybe jsm'izing could help with that? We're spending about 7 samples in waitForNextPaintOrBackground().

I

U

What is the status on this issue ?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #2) > U Argh! I... have some patches locally that I need to upstream. I will be at FOSDEM during the week end so likely at the beginning of next week.

Except for avoiding the forced reflow, I didn't find much we can improve here. We can turn off screenshotting, and that demonstrably helps, but that's a UX issue. We can allow the app frame to be visibility:visible before we fetch the screenshot from the DB, but - no "real" apps start up fast enough (yet!!! :) ) that keeping their <iframe> visibility:hidden for that interval makes a user-perceivable difference - not waiting on the screenshot from DB means we can jank from default-background -> screenshot in general

Not specific enough to be useful anymore. We squeezed a little bit of win out of this code.