Look-ahead optimisation, Reusability
Opened this issue · 10 comments
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!
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.
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.
Awesome, I'm looking forward to seeing what you come up with!
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.
Great, thanks for the update! When you have a Pull Request ready, please merge it into develop instead of master.
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.
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.
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.
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.
I'm closing this due to inactivity, but I'm happy to revisit this if there is a PR!