Jump to content
Search Community

Large element transforms (Page transitions) - advice wanted!

pm33 test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts



I am currently working on a project that requires full page transitions. As an example pages are div elements that are approximately 1024x600 in size and contain content. Pages slide in and out from left to right (emulating the ebook feel).
At the moment the page change/transition process goes like this:
* Page in view has visibility 'visible' and willChange '' set
* set willChange 'transform' on outgoing page
*Slide outgoing page out of view
* set visibility 'hidden' and willChange '' on outgoing element after animation finished
* set visibility 'visible' and willChange 'transform' on incoming element.
*Inserted delay (~300ms) - to allow some breathing room for browser paint times and composition(layer creation)
*Slide incoming page into view
* set willChange '' on incoming page  once animation is finished
I have put in the delay to give the browser time to paint and promote the div to a composite layer before animating for smooth animations. However the delay required on different devices obviously varies.
Is this something lagSmoothing can help with or does any one have any other/better techniques for this type of situation?
Jack has already suggested:
  1. Don’t alter the will-change property at all. 
  2. Take the layerization hit at a time that’s less critical. Maybe at startup (not sure how many things you may have to layerize, so you may have to stagger things). You can, for example do TweenLite.set(element, {force3D:true}) and it’ll get layerized right away. That way, when you actually go to animate its transforms, it’s already layerized and ready-to-go. 

My understanding was that setting will-change:'transform' on the element layerized when it is set, so is there any differences between using that or TweenLite.set(element, {force3D:true}) ?


The other thing is deciding when to layerize the pages. Because the pages are quite large doing all the pages ahead of time floods the GPU memory and would probably kill the device so it seems the only option is too layerize pages as they are needed. Since that can take some time depending on the device I am currently inserting the delay during the animation sequence to help but I would much rather a more dynamic approach (no need delaying on devices that dont need too or might need longer).


Any input or advice would be appreciated, thanks.


Link to comment
Share on other sites

From what I understand, the will-change property isn't widely supported in browsers yet. The TweenLite.set(...{force3D:true}) is a much more broadly-supported solution. 


Are you seeing an initial jump on some devices when you animate (without adding your 300ms delay)? Have you tried setting TweenLite.lagSmoothing() to different values? Like maybe:

//if there's a delay of more than 200ms between ticks, adjust the core timing mechanism to act like only 33ms elapsed to avoid a jump:
TweenLite.lagSmoothing(200, 33);

You can change the values anytime. So, for example, you could set it very low right when you're about to do your transition, and then once your transition starts, you could set it back to a higher value. 

  • Like 2
Link to comment
Share on other sites

With TweenLite.set(...{force3D:true}) will setting the opposite, TweenLite.set(...{force3D:false}) remove it from a composite layer straight away, on next tween or not at all? I need that sort of control otherwise GPU Memory will be an issue.


I will try adjusting the lagSmoothing. Would the process be something like:
* set TweenMax.lagSmoothing(300, 33);
* init and start animation Timeline

and then set it back to default on onStart, onComplete or would somewhere else be better suited?




Using TweenMax.lagSmoothing(40,17); seems to be working quite well.

Are these settings too low to leave on the whole time? Any major drawbacks?

Edited by pm33
Link to comment
Share on other sites

It's fine to leave those setting (most likely) - the only time it'd become a problem is if it consistently takes more than 40ms to render each frame/tick because every time that happens, it'd adjust things to make it seem like only 17ms had elapsed, thus your animations would appear to slow down. It's pretty uncommon, though. So the key is to check to see if you're running for long periods of time at less than 25fps (because 40ms between frames = 25fps). If you set it to 50ms, the threshold would be 20fps. And again, a hiccup here and there is fine - in fact, that's exactly what lagSmoothing() is for. The problem only comes in when you've got long spans of time below that threshold and the adjustment keeps being made. 


Make sense? 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...