Open prashantpalikhe opened 7 years ago
According to my research, in Chrome, if the main thread needs to hit the rendering pipeline, it basically asks the compositor thread (impl thread) to signal it when to start generating frame. The compositor thread listens to underlying OS's vsync api to detect vsync intervals and therefore knows when is the good time to draw, depending on whether we recently drew, when the next frame is and other things. When compositor thread tells main thread to begin generating frame, main thread does several things which includes calling raf callbacks, performing pending layouts and recording drawing calls (main thread-side painting).
So in the above situation,
Which in the flame charts translates to what we see
I guess that explains what we see in the flame chart. Would be great if someone with deeper knowledge on these internals validate whether its true or not.
In the repo, it mentions that the event loop tick picks out the oldest task in the queue, executes it, checks if rendering needs to be done, and after all that, moves onto the next tick.
So, with that in mind, if I have two timers installed with
setTimeout(fn, o)
and the first timer callback dirties the DOM.I would expect the event loop to do the work in following order:
But in Chrome's flame chart, I see
Whats the explanation for this?