|
|
|
|
|
by pcwalton
4346 days ago
|
|
Because, in general, they can trigger layout/reflow, so they can't run on the compositor. For example, changing things like "top" on an absolutely positioned box can trigger reflow of the contents inside, because of the way CSS works (for example, if "bottom" is set, then the height changes, which can affect the size of things with percentage heights, which can cause floats to be repositioned, etc. etc.) In traditional browser engines it's even worse because layout runs on the main thread, which is also shared with your JavaScript, so painting ends up transitively blocked waiting for your scripts to finish. That is not the case in Servo (disclaimer: I work on Servo), but making layout run off the main thread is hard for many reasons—some inherent to the problem, some historical in the design of current engines—so all current browsers run JS and layout together. |
|
To elaborate on how this works in Gecko. The rendering pipeline has several optional stages:
requestAnimationFrame (Scripts) -> Style flush -> Reflow flush -> display list construction -> Layer construction (recycling) -> invalidation -> Paint/Rasterization -> Compositing (on it's own thread).
Gecko tries to only run each stage of the pipeline only if they are needed. Fast operations like a CSS transition on an opacity or transform will only activate the Compositing phase. WebGL only canvas drawing will only activate rAF + Compositing. Meanwhile a JS animation on "top" will run all of these phases.