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
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
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
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
4 matches
Mail list logo