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

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

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

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

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

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