Jump to content


onUpdateParams' self parameter, how to set a property, force3D

Recommended Posts



I'm working on an animation where I animate the scale, and other properties of the body tag. The scale goes from a value of 1 to a bigger value to create an effect like in Prezi, to zoom in to an element of the page. Just as is, this makes the element shown very blurry, but I found out if I set the tween's force3D property to false, it will be sharp (good) at all times. But this also makes the whole animaton very laggy. I tried to change the force3D property while animating, so it renders only a few times during the animation, to both avoid blurriness, and lag, but I don't know how to set it in the onUpdate function. So my question is, if I set the onUpdateParams to ["{self}"], what can I do in the onUpdate function with that object? (I tried calling .set() and .updateTo() on it)

Link to comment
Share on other sites

force3D is not a property that can be toggled or set mid-tween. It's behavior is deeply tied to how the tween sets and records values (either using matrix3d or 2d transforms).


I recall a few times where folks have recommended not animating the body in that fashion. You may want to create a div that wraps everything and animate it instead. Not so sure that is going to yield better performance as scaling anything that is large takes effort and to optimize performance most browsers will be scaling a bitmap representation which is going to give you the blurriness. 


From what you describe, PointC's SVG viewBox tips seem like the best way to go.


Be amazed by the demo here:




learn more:



  • Like 4
Link to comment
Share on other sites

Carl is 100% right!   :rolleyes:  .. You should never animate the <body> tag, that should be the one constant in your page that is static. But its better like Carl advised to create a div that wraps everything and animate that instead.


Think of the <body> tag as your main foundation! This way you will save yourself headaches from animating cross browser. Since each browser will animate the body tag differently or not at all.


Keep in mind when animating elements you need to have their CSS position property to use absolute or relative, so they animate correctly, out of the flow of the document. So that is another reason why animating the body should be avoided :)

  • Like 3
Link to comment
Share on other sites

Thanks for the quick replies.
Here is an example page of the animation I described.

Now I understand the effect of force3D and what it does. I was working on the performance of this, but couldn't make any noticable difference. I made an additional wrapper to put the animation on, instead of the body, and tried some manual updates in the onUpdate function to animate the scale, rotate etc functions of transform instead of the matrix that the gsap does, but saw no benefit, so I reverted to the original.


The pages where I use this animation are generated in our digital signage system's content editor, and are much like slides, so that's why It wasn't that scary idea to animate the body first, because it's not a whole website.


Carl, the demo you posted looks cool, but I guess I can't use that in our system, because we use HTML5 based pages, and we couldn't migrate all of our features to svg.

Link to comment
Share on other sites

Hello srmark,


You are trying to animate very large images.. some of them are either almost 500mb to 2mb. So you should also optimize your images, that will definitely cause performance issue too.


I would still recommend to create the containing parent element instead of just animating absolutely positioned elements within the body tag as your parent.


In CSS when setting up  a animation, you always want a parent element with position relative. And then you will have nested child elements animating with position absolute. This way every browser will understand what is relative to what for your absolutely positioned elements.


You should have left that parent container you added.. since it will help with cross browser and make sure you get consistent results. The performance issue your seeing has to do with the way your appending elements with inline styles and having no reference of initial properties in your CSS style sheet.


Also your adding css properties with jQuery inline via jquery append method. You need to make sure you have the default position offsets in your style sheet or style tag. You have them inline on your element and then animating with GSAP So you need to be careful adding CSS with jQuery instead of GSAP, so it can know what is changed outside itself.. even if it is adding elements with inline styles with jQuery append() and or jQuery css()


So you a mixing a lot of jQuery methods when applying your CSS instead of letting GSAP handle the setting of CSS properties. Its best practice to first position your elements with top, left, right, or bottom in your style sheet. And then you animate with GSAP.. You are adding everything inline, and mixing GSAP with jQuery. that is why i see different results and performance in Firefox vs Chrome..


Im also see you animating elements with no default top or bottom and left or right offset property.. that will also cause issues with performance and consistent positioning.

  • Like 2
Link to comment
Share on other sites

Well, my guess on why is it laggy was your first thought too, using too big images, and also animating the whole page.


I meant to say that I reverted only the onupdate manual calculation things only. I left the plus container in, it was included even when you checked yesterday, and it does have relative position.


For this particular effect I set the transform-origin right before the animation started on the timeline, and that was with jQuery, but now I replaced with gsap set.


The other jQuery css property setter and append methods run at the loading of the page, only at the beginning, so I thought they don't affect the animation.


As I mentioned, this page is generated with our content editor, and the elements' style is set inline since a long time, many contents were generated this way, so even if I wanted to change some things that are in the source of the index.html itself, I couldn't, because we don't have a way to modify all of our generated html files yet. I can only modify my js file included in all pages, and a style sheet included in all pages, containing basic stuff.


So after clarifying these I would have some specific questions about what should I do:

1. Should I define the top and left properties of the main containers, even if they are constant 0px?

2. Should I take the elements' inline css properties when the page loads, and generate a style tag to put them into via javascript before the animations start?

3. Anything else?


Thanks again for the help!

Link to comment
Share on other sites

  • 4 weeks later...

Hey, I still have some questions in the above comment and I would appriciate an answer, thank you!

Link to comment
Share on other sites

Sorry, but its very difficult to advise you on this as we have no way of testing any of our theories and we aren't intimately familiar with what your content management system might be doing or the restrictions it applies. I'm doubtful setting top and left to 0 would do anything, but that is something you can test better than we can. likewise I don't imagine that ripping out inline styles is necessary unless their specificity is somehow impacting your animation or other factors. My best guess is that the browser is just struggling because you are scaling multiple large images at once. One way to test this theory would be to take all 3 images, reduce their size by 80%, drop them in the html and see if the results are better. I tried looking at your javascript but there are over 1000 lines and I can't try to dig through all that which is why we always ask for reduced CodePen demos


Again my best bet is that there is a rendering bottleneck in the browser, not and issue related to how fast GSAP can animate values. I'm sorry to say that I'm doubtful there is a single GSAP setting or css value that is going to make this perfectly smooth. 

  • Like 3
Link to comment
Share on other sites

Ok, thank you very much for your help!

  • Like 1
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.