try animationFrames to improve Painting time

[nkuehn]

Hi @0x8890 , I really like this slim DOM focuesed thing!

As painting is the biggest remaining time block (in a zero-layout page!) It could be interesting to research anmationFrames to improve rendering performance due to DOM thrashing. I have experienced ( on mobile ) that it sometimes makes a relevant difference and sometimes not. It's interesting as simulacra "knows" DOM changes that belong together and should be wrapped in one rendering pass.

This guy did a good writeup: http://wilsonpage.co.uk/preventing-layout-thrashing/

[gr0uch]

I thought of implementing this as a feature but it is not so good for predictability. Consider this case:

data.key = 0; data.key = 1; data.key = 0;

If requestAnimationFrame is used here to render, the DOM will not mutate at all, and this doesn't play well with other APIs such as MutationObserver. Simulacra.js already minimizes DOM manipulation, i.e. in this case:

data.key = 0; data.key = 0; data.key = 0; // and so on...

It will trigger at most 2 DOM updates (removeChild/insertBefore). Also it is possible for the user of this library to throttle updates themselves:

data.frame = 0; requestAnimationFrame(function () { data.frame++ });

In my opinion the cause of problems would be "data thrashing", which leads to "layout thrashing".

[nkuehn]

You're right in that the "user code" side has better control over wrapping and can also optimize better because it can wrap even bigger sets of layout changes in an animation frame.

Concerning the Mutation Observer issue I'm not sure if it's a feature or a bug. To me the point of mutation observers is to only do stuff if the node has effectively changed and the change is really done. So to me that is rather a feature that prevents follow-on bugs.

Did you try out whether the observer is not triggered when effectivly nothing changed in an animation frame? Interesting aspect an as I couldn't find it in the DOM spec it could well be that browsers are doing it differntly :-(
It would actually make me wonder because the intent of the animation frame is actually just "please wait for the next frame until you start doing this so that you don't accidentally do it across two frames"

PS: If you do fast and small a=1 a=2 a=1 without an animation frame it will most likely fall into the same Graphics rendering frame anyways, the real layout thrashing including the OS graphics stack is happening only on bigger sets of changes that don't fit into a typical framerate frame anyways.

[gr0uch]

Hmm, to me it doesn't seem like much of a benefit to implement asynchronous DOM updates, here's why:

• Less consistency in when DOM updates happen.
• Higher idle CPU usage, since requestAnimationFrame may run 60 times per second.
• More complexity in implementation.

The only use case that this could benefit is rapidly changing values within the same tick, and for this case it would be better if the calling code throttles this.

[nkuehn]

+1 you're right, overall effect of what the calling code can do is way higher.