Clipped elements in Chrome when animating

[Dave Stewart]

I mentioned in a post a week ago or so that I was noticing some of my elements (namely, test squares in CodePen) kind of squashing in the direction they would animate in. It would be fairly significant for a 50px wide box, squashing down to maybe 20px or so.

 

I was using a timeline, and this would happen for the first few animations until it kind of leveled-out, leading me to believe there might be some kind of caching going on under the bonnnet.

 

Anyway, I know now that's not the case, but my latest test animation (TweenMax, not TimelineMax) has thrown up the same issue, and it appears to be clipping, not squashing.

 

Note the front of the van - it's missing!

 

 

Here's a video of it in action: youtube.com/watch?v=eUQD71nDCyY

 

The original Pen is here: 

See the Pen rwsBa by davestewart (@davestewart) on CodePen

 

It only appears to happen in Chrome - mine is 35, Windows 7.

 

Anyone else got or get this?

 

Cheers,

Dave

[Jonathan]

Hello Dave,

 

I just tested your codepen on Windows 7 Pro (64-bit) - Chrome 35 & 36 and I did not see the issue on both versions.

 

Maybe it is your graphics card? .. or a Google extension?

 

I did notice you are animating theCSS left property. For a smoother animation and being able to push your animation into hardware acceleration.. I would suggest you use x instead of left.

 

The CSS left property can not animate on a sub-pixel level.. but if you use the x (translateX) property in GSAP then you can do sub-pixel rendering.. it will move the render from the CPU to the GPU.

 

So the left property could only animate 200px .. wheras animating the x property would be able to do 200.9888277px .. so you don't get that step effect type of animation.

 

More info her on what i just described:

 

Article on CSS-Tricks by Jack Doyle Myth Busting: CSS Animations vs. JavaScript

Why Moving Elements With Translate() Is Better Than Pos:abs Top/left

 

Hope this helps

[Dave Stewart]

Alas no! It still exhibits the same behaviour (though seems to sort itself out after a few goes).

 

You're right about using x; I know that kicks in the GPU. Old habits die hard

 

If / when I do use x, any idea how to extract the value later for the wheel rotation?

 

$(el).css('x') isn't going to cut it. And I can't see a TweenMax.get() !

[Jonathan]

You would access the GSAP _gsTransform object to get the current x value.

 

i forked your example with changes:

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

// callbacks
function onUpdate()
{
    var x = parseFloat($van[0]._gsTransform.x);
    rotate($wheels, x, c);
}

Also you can add force3D:true to your set() to make sure GPU is enabled.. which is part of the CSSPlugin.

• force3D - when you set force3D:true, it forces GSAP to apply a 3D value to the element's transform, meaning matrix3d() instead of matrix(), or translate3d() instead of translate() which typically results in the browser putting that element onto its own compositor layer, making animation updates more efficient. In other words, setting force3D:true usually boosts performance, making movement more smooth. However, if you exceed the GPU's memory limit, performance will degrade, so it's not wise to force3D:true everything all the time. See http://css-tricks.com/myth-busting-css-animations-vs-javascript/ for more details. In our experience, though, it helps performance more often than not. The default value is false.

// functions
function rotate($el, x, c)
{
    var r = (x / c) * 360;
    TweenMax.set($el, {rotation:r, force3D:true}); 
}

The equivelent of x in CSS is translateX() .. see CSS Transforms .. GSAP equivelent in bold:

 

translateX = x

translateY = y

translateZ = z

rotateX = rotationX

rotateY = rotationY

rotateZ = rotation

scaleX = scaleX

scaleY = scaleY

scaleZ = scaleZ

 

Does that help?

[Rodrigo]

Hi Dave,

 

You can use the _gsTransform object to get the CSS transform values GSAP is tweening:

TweenLite.to(element, 1, {x:300, onUpdate:getValues, onUpdateParams:["{self}"]});

function getValues(tween)
{
  console.log(tween.target._gsTransform.x);
}

[Rodrigo]

Well.... Jonathan's faster than me

[Jonathan]

Haha Rodrigo.. most of the time, i'm slower than you

[Dave Stewart]

Sweet! All good info there chaps.

 

Weirdly, I still get the clipping, even in 3D.

 

I miss Flash

[Jonathan]

Yes I miss Flash too Dave!

 

I tested with a NVIDIA Quadro 600 graphics card - Windows 7 Professional (64-bit) - PC

• Have you tried viewing in another PC with Windows 7, to see if you see the same clipping?
• Also is that real PC windows 7 or is it VMware /  Virtual Environment?

[Rodrigo]

Hi Dave,

 

Have you tried making the animation  longer/shorter?, This happens only in Codepen or also in a local environment?.

 

I have a gut feeling that this has more to do with browser-rendering issues than GSAP, but to be sure we need to try some stuff.

[Carl]

Thanks for the video, Dave. VERY helpful. In your original post about the boxes squashing I really didn't follow what you were saying.

 

This video make it very clear. I'm certainly surprised by that behavior as I've never seen anything close to that. I can certainly see how it is undesirable. 

 

I'd be very curious to hear if anyone can replicate those results. Like the others have noted, I'm leaning towards this being very specific to something in your hardware. If this issue were more rampant I'm sure we would have heard about it. I'm very puzzled.

[GreenSock]

I can virtually guarantee that this has absolutely nothing to do with GSAP. It has all the markings of a weird issue in Chrome on your particular system (perhaps with your video card). I tried your codepen many times and I could NEVER get it to display something funky like in your video. Very odd. 

 

You said you tried adding force3D:"auto" (or true), right? Just curious - sometimes that fixes some weird rendering glitches in Chrome for me. Again, it's a Chrome thing, not GSAP. I really wish we had a magical fix, though.