Re: Figuring out and controlling what tasks run before first paint

2017-08-09 Thread Honza Bambas
What you are looking for sounds pretty much like my Backtrack project [1]. It's still under development, tho, but I have strong motivations to move it forward in Q4/17. The goal of Backtrack is exactly what you are looking for - find the right scheduling prioritization. It's said we don't

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Gregory Szorc
On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione wrote: > One of my biggest frustrations in profiling startup performance has been > the fact that exactly which code runs during before or after first paint > changes based on arbitrary timing factors. If I make a 5ms

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread zbraniecki
During FxOS days we spent a lot of time designing the "bootstrapping" stages of the app/system. We came up with 5 stages: 1) navigationLoaded 2) navigationInteractive 3) visuallyLoaded 4) contentInteractive 5) fullyLoaded

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Kris Maglione
On Tue, Aug 08, 2017 at 06:09:05PM -0700, Robert Strong wrote: One thing that comes to mind is how some code registers app specific observers so the code runs after the UI is displayed. ... Perhaps having a single category for after UI has been displayed that components can specify in their

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Robert Strong
One thing that comes to mind is how some code registers app specific observers so the code runs after the UI is displayed. https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180 https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24

Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Kris Maglione
One of my biggest frustrations in profiling startup performance has been the fact that exactly which code runs during before or after first paint changes based on arbitrary timing factors. If I make a 5ms improvement to one section of code, a 100ms chunk of code winds up running after first