Prevent multiple style recalculations and improve performance by grouping DOM reads and writes

[rikschennink]

Is your feature request related to a problem? Please describe.
When requesting offsetLeft (or other DOM reads) in the beforeUpdate callback the browser has to recalculate styles when the styles are changed in a further update. See below how this looks in dev tools with multiple components (the second one is without the DOM reads, you can see the recalculation is done after every style has been updated).

I've created a REPL: https://svelte.dev/repl/1977c00357cc496eae5ec1f2a9d23675?version=3.12.1

Multiple recalculations because of DOM reads

Single recalculation

This slows down the frame render.

Describe the solution you'd like
If we can schedule all reads before the update happens DOM reads are free (the browser has prepared the frame) and don't cause additional style recalculations. This might require setting up a global draw loop so web components created with Svelte all use the same read/write order.

Describe alternatives you've considered
I've moved the DOM read to afterUpdate while that does group part of the writes we only get the info after the update while we need it before.

How important is this feature to you?
Very. It's super useful to be able to access layout information at the start of the frame (it's free at that moment) and this can be used to for example calculate the width of a component and then layout its children accordingly (simulating component queries) without affecting render performance. I use this extensively in FilePond.

Hmm, I remember looking at how to integrate FastDOM but decided against it because I thought I saw these reads already wrapped in a RAF.

[rikschennink]

@dkondrad it doesn't group the reads of all components so it's still problematic.

I ran the test again with 130 bars and the difference (reading the DOM vs not reading) is dramatic.

With DOM reads in beforeUpdate

Without DOM reads

The "run with FastDOM demo" shows that as long as the reads are grouped, you get a similar chart.
https://wilsonpage.github.io/fastdom/examples/animation.html

@rikschennink,
Good to know!

I added fastdom to your repl and I can achieve the same performance gain that you mentioned.
https://svelte.dev/repl/6df68ea571574563b722b7ea157ea98c?version=3.12.1

I'm not sure if this belongs in the core code though because not everyone will be performing these kinds of reads/writes. Also, it is trivial to integrate fastdom and make use of it, as I've demonstrated.

[rikschennink]

@dkondrad While it does group the reads (which is nice) it also results in two requestAnimationFrame calls.

The value retrieved within the measure function in beforeUpdate is not available in afterUpdate or the template, (as it's returned in the second raf).

[joseDaKing]

Hi, everybody I am by no means an expert, but popmotion framesync library might be helpful here because it gives you more control. Framesync can do the following splits a frame into discrete read, update, preRender, render, and postRender steps. If you don't want to use this library you should at least have a look at it's code.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Oh my gosh this stale!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope