Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Raymond Chow

Animation quirks and inconsistencies across browsers

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 everybody. I'm new to forums here but not to using Greensock. Also in the transition of switching from Flash to CSS/Javascript. I'm finding it to be a rough ride so far. Anyhow, I've been playing around with using CSS transforms via TweenLite/TweenMax and noticed the results seem to vary across browsers. Not to mention the strange animation jitters that happen.

 

Hopefully I'm setting up the codepen correctly (I'm new to that as well):

See the Pen evAto by anon (@anon) on CodePen

 

On Firefox 28 I see a slight jump at the end of the animation. On Chrome the individual letters jump around slightly for the entirety of the animation. "Force3d: true" doesn't seem to help smooth out the animation either. Don't know if it makes a difference but I'm using the PC versions of the broswers I mentioned. Weirdly enough, on IE 11 it seems to run perfectly...totally smooth and not a single bit of jittering. Don't know if I'm just doing something wrong, if it's a browser specific bug, or if it's something on GSAP's end. Any help/insight on dealing with this would be appreciated. Thanks!

 

-ray

 

Link to comment
Share on other sites

Hello Raymond Chow, and Welcome to the GreenSock Forums!

 

You have in your code Force3d .. but it should be force3D:

 

I modified your example:

See the Pen GKDgt by jonathan (@jonathan) on CodePen

 

i don't see the jitters when force3D:true is set.. do you see the jitter still?

 

Also you don't have to include the body tag in codepen since the HTML panel is the inner contents of the <body> tag. Plus its always good to specify a parent <div> or HTML tag that will have position:relative CSS property so your absolutely positioned element knows what its relative too.

 

I hope this helps.. let us know if you need any more assistance? :)

  • Like 1
Link to comment
Share on other sites

Thanks for the reply Jonathan! Oops, I was wondering the force3D didn't fix that on Chrome. It is smooth now on Chrome but now the downside is that it is scaling up what seems to be a bitmap version (I'm assuming this has to do with how the GPU hardware acceleration works?) and looks noticeably blurry. It stays blurry at the end of the animation for me. On Firefox it still has that same slight jump at the end of the animation but doesn't have that blurring issue. IE looks perfect still (I'm in shock by this).

Link to comment
Share on other sites

Hey rhernando, thanks for showing me that. I opened up the Codepen example that Jonathan made after following that thread you referred me to:

 

See the Pen pqwrs by jonathan (@jonathan) on CodePen

 

It seems like Firefox has the same issue with my first example. Except in this case it happens after you mouse off the hex and it shrinks back down to the original size. The text does a slight

shift/jitter thing. I took a video of it to show what I mean but I'm not sure what's the best way to share it on the forums.

Link to comment
Share on other sites

Hello Raymond,

 

Yeah I see that behavior too. That codepen example has the scale on the text being animated from 0 to 1.2 ... but Firefox has a bug for that slight shift/jitter thing we are seeing on the scaled text after it finishes the animation. This behavior has nothing to do with GSAP, but is a Firefox browser bug.

 

Firefox Bug 633097 - Transitioned objects jitter with scaling transform

 

Also here is fork of that forked, and you got it...  :blink:  forked again example from above, that fixes the shift/jitter thing in Firefox.

 

Firefox text scale shift/jitter thing fix:

See the Pen dJgex by jonathan (@jonathan) on CodePen

 

Since Firefox has that bug .. this is what i did:

  • I increased the font-size from 12px to 14px on .hex in CSS panel
  • instead of setting the initial scale to 1.2 .. I scale the text to 1 which sets the text at 100%
  • and setting the scale to 1 for the tween in the mouseleave event

Then you don't get that jitter after it completes the animation.

 

Hope this helps? :)

Link to comment
Share on other sites

I almost thought whole numbers for the scale would be partial workaround but it seems that's not the case. I used 3 to scale up to for the mouse over and it would do the slight jitter at the end of it:

 

See the Pen jKDFn by anon (@anon) on CodePen

 

It's too bad about it being a Firefox bug. Seems like that bug has been there for awhile too. Sure makes it a tad impractical to use scaling in the future unless the designs/type conforms to certain sizes that won't cause it to jitter.

Link to comment
Share on other sites

Ok.. i only see that jitter behavior after it animates in Firefox when scaling text ..

 

But here is an example of animating the font-size instead of using scale to resize the text due to that Firefox jitter bug. This is so we can just isolate the mouseenter and mouseleave tweens, to test with:

 

Hover over Mr Lizard in Firefox:

See the Pen ryKGj by jonathan (@jonathan) on CodePen

 

The text scale is being animated with scale

The text font-size is being animated with fontSize

 

Even adding properties like perspective, transform-style, backface-visibility only help a little..

 

But.. if you add rotationZ : 0.01 and z : 0.001 to the hover tweens, then the shift/jitter thing doesn't happen after the animation completes, Open the following link in Firefox:

 

No jitter but now blurry like webkit bug:

See the Pen Hlwds by jonathan (@jonathan) on CodePen

 

You see the text scale becomes blurry when hovered, like it does in webkit bug .. So by solving the shift/jitter thing, now blurry text is our new enemy.. so i guess we can hope Firefox fixes that bug, since it has been around since 2011 ...

 

So either way we cant win :(

 

:)

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