4 ms·
To clarify a bit: the passive event listener idea is a good start because it means the scrolling thread doesn't have to block on the main JS thread. But it see
by iainmerrick 9y ago
To clarify a bit: the passive event listener idea is a good start because it means the scrolling thread doesn't have to block on the main JS thread.
But it seems like a big use of scroll handlers is to reposition some elements on the page, e.g. for parallax scrolling. Ideally that should synchronize exactly with the rendering thread, so elements don't jiggle slightly out of position as you scroll. The best way to do that is to run the scroll handler in the scrolling thread -- as long as you can avoid waiting for another thread.
- mnarayan01 9y agoConsider the need to block on e.g. the DOM.
- iainmerrick 9y agoMultiple threads have to synchronize their DOM reads and writes, sure, but that doesn't mean all access needs to be single-threaded. I guess what I have in mind is roughly like managing DOM and JS state via STM, and speculatively parallelizing the JS. I don't know enough about STM to know how well it works out in practice, and for what kind of workloads. The goal would be to improve JS latency (ability to run small functions quickly) even if it reduces throughput. This is all pretty speculative, I realize, I'm just wondering if there are obstacles beyond all the obvious ones, like having to rewrite the entire JS and DOM implementations. :)