This takes a similar but slightly different approach to the linked PR.
The frameloop was originally a very small standalone library (and could be again?) so there's a focus on filesize where performance isn't really affected.
As the .reduce was the smallest implementation and is only called twice, this was chosen here.
The linked PR introduces a hoisted runNextFrame which is a good idea, probably the source of the "hot" function so makes sense to define it just once.
Here I've taken the linked PR's idea of unrolling the render steps but, instead of doing it in performance-insensitive areas where there's that trade of bundlesize, doing in the render loop itself which runs every frame and is highly performance sensitive.
Finally I've taken the linked PR's approach of replacing the forEach in the cancel function with a for loop, removing a function assignment. It should be that cancel is performed quite infrequently but it's also true that you never know.
kurtextrem
commented
4 months ago
Closes https://github.com/framer/motion/pull/2720
This takes a similar but slightly different approach to the linked PR.
The frameloop was originally a very small standalone library (and could be again?) so there's a focus on filesize where performance isn't really affected.
As the
.reducewas the smallest implementation and is only called twice, this was chosen here.The linked PR introduces a hoisted
runNextFramewhich is a good idea, probably the source of the "hot" function so makes sense to define it just once.Here I've taken the linked PR's idea of unrolling the render steps but, instead of doing it in performance-insensitive areas where there's that trade of bundlesize, doing in the render loop itself which runs every frame and is highly performance sensitive.
Finally I've taken the linked PR's approach of replacing the
forEachin thecancelfunction with aforloop, removing a function assignment. It should be thatcancelis performed quite infrequently but it's also true that you never know.