Jump to content
GreenSock

Ro1

Smoothness and EM values

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

Hi all,

 

Using an EM-value for Y fails. My tween changes for example

{ x : 1920, y : '-3em', z : 0.1 (for hardware acc.), scaleX : 1.5, scaleY : 1.5, scaleZ : 1.5 }

This gives me a matrix3d.

 

Is this a bug?

 

Using EMs for TOP works perfect though..

 

 

Also I find the transitions not very smooth on chrome and android (both chrome and normal browser (htc one)). Even now I've made them matrix3d.

IE10 and Firefox are fine. I cannot test it on ios right now.

 

 

Not tested it yet, but are x and y properties always converted to CSS3 transform / matrix ? Them, in combination with Z, I need to use modernizr or "if lt ie10" for hardware accelleration ?

 

 

Thanks in advance!

Link to comment
Share on other sites

Please read this thread:

http://forums.greensock.com/topic/8148-animating-x-with-percentage/

 

As far as things being smooth, are you saying things are a bit jerky on an Android device? (I wasn't sure if when you said "Chrome" you meant Chrome for a mobile Android device or the desktop browser). Please keep in mind a few things when looking at performance:

  1. Mobile devices in general (especially Android devices) tend to have very underpowered CPUs, so they're just plain slow anyway you slice it (compared to desktops). We can't fix that unfortunately - it has nothing to do with GSAP.
  2. In the vast majority of cases, the performance bottleneck (by FAR) is graphics rendering in the browser, NOT JavaScript code execution (GSAP). So, for example, it may take GSAP 0.001 seconds to alter the x and y properties of an element, but the browser may take 0.25 seconds to actually render those pixels in the new positions which, again, has nothing to do with GSAP. So minimize how much you're forcing the browser to repaint. 
  3. Try setting force3D:true on any transforms you're doing with TweenLite/TweenMax. You only need to set that once for an element, and it'll remember. Like TweenLite.set("#yourElement", {force3D:true}); That'll make it use 3D transforms which typically get offloaded to the GPU for compositing and that tends to be a lot faster than the CPU. 
  • Like 3
Link to comment
Share on other sites

Hi Greensock,

 

Thanks for your quick answer, my reply is somewhat late, sorry ;-)

 

 Quote from that thread:

 

 

To do it accurately, it'd likely be very costly performance-wise since every update would require analyzing the element's size and then convert % into px for the matrix. Remember, it's technically possible for the element's size to change during the tween - hence the need to keep running the analysis on each update (typically 60 times per second).

 

 

I agree, if you do want to analyze the element's size on every update. And analyzing and converting to a absolute value is no effort before start animating.

 

1.

With Chrome I meant both Chrome on desktop and on Android. The HTC One (and ony Xperia Z1) I tested it on are recent, high-end devices. I assume they are not that slow..(?)

 

2.

I'm animating 5 small elements (60px, 2 times X, Y, scale difference. 3 times only the X is different), 2 opacity's for full screen div's and 1 or some more elements sliding in.

 

3. Is force3d:true a substitute for adding a e.g. z;0.1 value ? So instead of { x:, y:, z:, scaleX:, scaleY, scaleZ } I can set a force3d:true and use { x:, y: scaleX, scaleY } ? Not setting the scaleZ gives me aan combined animationm, with scaleZ I get a matrix. Is there a difference in performance between a combined "translate3d(x, y, z); scale(x, y)" and a "matrix3d(..,..,..,..,..)" ?

 

3.1.

Using force3d:true, whould that kill the downgrade to animating left, top for not 3d animation supporting browsers?

 

Thanks!

Link to comment
Share on other sites

Yes, force3D:true is a substitute for adding z:0.1. And as far as performance differences between matrix3d() vs translate3d() scale(), it varies slightly by the browser but you'd probably never notice a difference in a real-world project. 

 

No, using force3D:true shouldn't kill any animation of top/left. The force3D only affects transforms, and GSAP is smart enough to ignore it in browsers that don't support 3D. 

  • Like 3
Link to comment
Share on other sites

Great. I tested it already and indeed, the fallback keeps working. I tried removing the backgrounds on the project and my animations performed a lot better, so it is the graphic rendering you've talked about. It's a pity that mobiles are that jerky so soon. :-(

 

Thanks for your help!

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.
×