Read/write batching for render loop

[mattgperry]

Hey team!

I was about to write a guide for integrating Lenis with the Motion render loop and it got me thinking about how reads/writes are batched within Lenis. I've seen style thrashing when Lenis has been incorporated into Framer sites because of this and I think I'd still run into the same problem with frame.read(lenis.raf, true) or whatever.

Have you ever though of exposing two manual raf functions, one each for reading (functions like limit) and writing (setting scroll position)? This way it could be set up like

frame.read(lenis.measure, true)
frame.render(lenis.render, true)

[clementroche]

Hi @mattgperry, thank you for sharing the knowledge with us. TBH we're not very familiar with framer and this example has been suggested by a pull request. I didn't know that Motion frame integrated this advanced read/write feature, which I like a lot (finally someone understands how important is performance).

Lenis is designed to avoid "style thrashing" as much as possible. For instance, This limit value you mentioned is calculated using debounced ResizeObserver and resize listeners, meaning that calling lenis.raf should not (as far as I know) trigger any "reflow" or "style trashing".

Now that said I've been looking for a way to rely on scrollHeight and clientHeight instead, so the content option would not be necessary making Lenis less DOM dependent and also much more reactive (since they are native values). That's why the __experimental__naiveDimensions option exists but it causes "reflow" on each wheel input.

As you described it in the Motion documentation, lenis.raf should be called using frame.render even though it's using window.scrollTo (which should not trigger "style trashing").