search

jeremyckahn / shifty

The fastest TypeScript animation engine on the web
https://jeremyckahn.github.io/shifty/doc/
MIT License
1.54k stars 88 forks source link

Look-ahead optimisation, Reusability #66

Closed ghost closed 6 years ago

ghost commented 9 years ago

Hi, It's been a while, but I'm back. :) One does not simply stay away from Shifty. I have a few power optimisations in the backlog that I want to address. First of all, just to get warmed up, I want to add support for LOOKAHEAD tables inside Shifty. Second, I want REUSABLE Tweenables. I am using Shifty on mobile (PhoneGap) and I want to squeeze every bit of performance out of the webview. But to avoid stuttering due to inefficient garbage collection in the webview, I need to reuse the objects (tweenable instances), and not use the default create/destroy cycle. Lookahead could be enforced through a Tweenable setup option (lookaheadOptimisation : TRUE). When this is used, we translate performance gain into data, meaning that we are not doing math computations while running the tweenable's lifecycle, but instead, precompute all the values for each frame in advance, in an Array (arrays are still the fastest and most comprehensive JS data structures for reading). Depending on the duration of the tweenable and the framerate, that's going to be a big array, but it pays off in performance. Some usage scenarios include big background animated layers and situations where many objects are animating at the same time. On the reusability side, I have to check the current state of Shifty. In the past (a few months ago) there were some issues that stopped me from reusing the same tweenable instances. Will check it out and continue from there. It's good to be back to Shifty-ing. Cheers!

jeremyckahn commented 9 years ago

Hi @adrianvoica, good to hear from you. I really like this idea! Performance improvements are always welcomed. I'm open to incorporating this improvement into the library, so long as it doesn't create backwards-compatibility issues with the API or behavior. If this significantly increases the size or complexity of the core, it might make sense to turn this into an optional module (like string interpolation or custom Bezier curve support). Is this something you were planning to put together a Pull Request for?

Also, please open a separate issue if you run into trouble reusing Tweenable instances.

ghost commented 9 years ago

Yes, I'm looking into a fully functional Pull Request for lookahead table optimisation. It will not break compatibility in any way. It will just bring a big (or, should I say huge?) performance increase when dealing with many Tweenable instances (as in 50+ independent tweens) - and, let's not forget, battery savings. There's still lots of work to do, but this feature will bring some stamina to the mobile webviews for doing cool interpolations. I'm also thinking on further optimizing this using shared variables - for instance, 2 or more Tweenables that use some identical start/end/lifetime variables could benefit (space-wise) from sharing a single instance of that variable - but this is just on a ToDo level for now. Back in the day, when I was coding stuff on Intel SX CPUs (no FPU), lookahead was the solution to most of the problems related to heavy computations. It never gets old. Cheers.

jeremyckahn commented 9 years ago

Awesome, I'm looking forward to seeing what you come up with!

ghost commented 9 years ago

Work in progress, going well under schedule. I have found a really good way to use a data-pooling mechanism (share pre-baked data across "registered" tweenable objects) that helps avoid flickering, by avoiding garbage collection - and gaining some real measurable speed increase. Coming soon to a Pull Request. Stay focused.

jeremyckahn commented 9 years ago

Great, thanks for the update! When you have a Pull Request ready, please merge it into develop instead of master.

ghost commented 9 years ago

You can close/delete this, as it will never happen in Shifty. After I gave it a good thought, it is not in the concerns of Shifty to do this. It might be a new library, concerned with actual frame values for each property, but not Shifty. I am building a (so called) Frame Player with this, as we speak, and I will make it open-source once I have something solid. Cheers.

jeremyckahn commented 9 years ago

That sounds reasonable. While agree that such an addition doesn't belong in the core, it might be useful as an additional, optional module. In either case, I look forward to what you come up with in terms of an implementation for this feature!

If it helps, this feature may also be a good fit as an addition to Rekapi, which is built on top of Shifty, since that is more concerned with frame values.

ghost commented 9 years ago

I'm back at Shifty (can't stay away from it!). So, let's reopen this issue, and I will take care of it. It will be implemented in a module called "FastForward" :). Working on it.

jeremyckahn commented 9 years ago

Sounds great! I can't wait to see what you have. Let me know if you'd like any help integrating the feature into the codebase.

jeremyckahn commented 6 years ago

I'm closing this due to inactivity, but I'm happy to revisit this if there is a PR!