4 ms·
This allows the browser to delay all style, layout, and paint work on attached DOM, and then also spread that work across multiple frames during a commit, reduc
by spankalee 8y ago
This allows the browser to delay all style, layout, and paint work on attached DOM, and then also spread that work across multiple frames during a commit, reducing jank for the unlocked portions of the page.
If you synchronously swap a large portion of DOM, style, layout, and paint will likely blow your frame budget.
- ballenf 8y agoEither I don't understand double buffering very well (not unlikely) or I don't know what you mean by "frame budget". Wouldn't swapping one buffer for the other be faster than most or all of the computations going into calculating that background buffer and easily doable in a single frame? What am I missing?
- deleted 8y ago[deleted]
- dfox 8y agoNormal double-buffering involves doing something trivial at the moment of buffer-swap, like changing pointer or at most doing large-ish memory copy. Double buffering DOM would either not solve the problem (in the case of doing the layout computations in background and then swapping already layed out DOM) or would involve doing all the layout computations at once when the swap happens (with the implication of this being mostly equivalent to loading new page and thus slow and in many cases too slow to happen at 30, 60 or whatever Hz)