-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latency and performance #9
Comments
I see the throttled helper function in the source so I guess my first question is answered. |
The main concept for Tornis was that I wanted to handle all input-related events independently and have the rAF function only handle the render updates. The rAF function itself is also limited to only fire when something has changed. Certain native events are throttled (as you've spotted), whilst others, like velocity, are captured using an averaged array of the most recent values. Throttling the native events causes gaps in the delta calculation used for velocity, in-turn causing the value to fluctuate back to zero. Pushing the delta values into an array and averaging them smoothes out the fluctuation and, whilst not 100% accurate, gives a much more representative value. All that said, I've not experienced that level of latency before. Would you be able to share your browser set up with https://mybrowser.fyi ? |
Wow sorry looping back after all this time. https://mybrowser.fyi/report/5ed878792ba61600152538fd Curious what do you use 'under the hood'...any touch event library? We are considering a touch handler revamp because we have sticky headers, a side menu, a swipe navigation and more all listening to the touch handlers to determine distance, direction, angle, etc. Becomes a lot. But I guess you know that and assuming that is where Tornis might work well. But kind of wondering what people are these days...touch handler or pointer events, and if touch handlers still any lib thats standard with rAF and debouncing and preventDefault these days that's a 1 trick pony that you know of? Pretty good thread too on that https://stackoverflow.com/questions/49541173/how-to-prevent-default-handling-of-touch-events |
Based on this descriptor... "Rather than bind directly to native events, Tornis throttles them and captures only the bare minimum - the updated values. An optimised render loop with the requestAnimationFrame api updates the store and provides the new state to any subscribed functions. This means that your code only runs when the store has changed, and when the browser is ready to render." is the rAF itself the 'throttle' (meaning conceptually throttle) or it is using vanillaJS throttle?
I am wondering on a few of the demo examples there is >1 second latency on some variables updating most notably the velocity measurements. I stop touch/mouse movement and more than a second later it finishes updating. This could be huge in touch events. Is that due to how the velocity is calculated? Any ideas on added performance overhead using this abstraction in something like scroll usin rAF? Ever used in conjunction with a batch read/write lib like FastDOM?
Thanks so much, super interesting library.
The text was updated successfully, but these errors were encountered: