Update 3.12.3 broke my code for animating clip paths?

[skiller]

Just a quick note regarding the recent update to 3.12.3 (more details to follow later):

 

Merely 17h before the project deadline all of a sudden animated clip paths (CSS+SVG) stopped working.

 

Since GSAP was the only component that was updated recently, the latest update was a likely culprit, and reverting back to 3.12.2 resolved the issue.

 

In short terms:

I have an SVG path (normalized to a width of one and .5 units from the origin point), which I use as a clip path via matrix(1, 0, 0, 1, .5, .5).

While GSAP was able to show a set matrix of matrix(0, 1, -1, 0, .5, .5) – a 90deg rotation –, it couldn't interpolate, so I ditched the rotation.

I was able to have GSAP correctly interpolate a scaling Tween from (0.01, 0, 0, 0.01, .5, .5) with 3.12.2, but with 3.12.3 the clip mask suddenly flew in from the lower right corner.

 

I'll post more details when the project is online, I just wanted to give a quick head-up so you can investigate in the meantime, if you like.

 

 

Best regards

C.

[GreenSock]

So sorry about that, @skiller! That's terrible that it happened right at your deadline. I'm super curious to see a minimal demo that illustrates the problem - I'd like to get it fixed immediately.  Would you be able to create a simple CodePen maybe?  I didn't quite understand what you meant about GSAP not being able to interpolate a rotated matrix too. I've never heard of that before and I can't imagine why it'd be a problem. 

[skiller]

Sorry for the delay, but I finally got around to making two minimal examples:

 

GSAP 3.12.2: 

See the Pen rNPPGLy by ehrenstein (@ehrenstein) on CodePen

 

GSAP 3.12.3: 

See the Pen qBggPXY by ehrenstein (@ehrenstein) on CodePen

 

The 3.12.2 version works okay, although the clip path rotation isn't around its center (= translation point given through the transformation matrix as .5,.5) as it should, the 3.12.3 version has the identical code, I just swapped out the GSAP version given in the JS settings.

 

The clip path was designed to be within a 1 × 1 (unit-less) square so it can be used relative to the clipped object's dimensions (clipPathUnits="objectBoundingBox"). A transform translation of .5,.5 should thus always be understood as the clipped object's center.

 

 

Best regards

C.

[skiller]

The problem with the project was that I had envisioned a slick animation of an object coming out of a space portal 😎(hence the animated clip mask) and sort of found a workaround/tweak/patch for the dented clip path rotation with 3.12.2. There was also a “swirl” graphic of the same dimensions layered on top of it, and since it was a nightmare to align well with the tweaked 3.12.2 clip path rotation and the havoc from the 3.12.3 version I ended up playing it safe and threw out the whole portal rotation.

[skiller]

* bump *

[GreenSock]

Thanks so much for the minimal demo, @skiller!

 

Here's a preview of the next release - better? 

https://assets.codepen.io/16327/gsap-latest-beta.min.js

 

See the Pen VwgOEvm?editors=0010 by GreenSock (@GreenSock) on CodePen

 

I'm also curious why you were setting transforms with a matrix. It's almost always best to set transforms directly via GSAP instead of in CSS, and use the individual components (x, y, scaleX, scaleY, rotation, etc.) instead of "transform: matrix(...)" because: 

1. Accuracy. Matrices are inherently ambiguous in terms of deciphering the component values - rotation: 180 is the same matrix as scaleX: -1, scaleY: -1, for example.
2. Performance. Every time you try to animate the entire "transform" value, GSAP has to parse all the individual components whereas if you just animate the components, GSAP can use the cached values which is much faster.
3. Readability
4. Flexibility - what if, for example, you want to animate the "y" over the course of 1 second with an elastic ease, but "scale" over the course of 2 seconds with an ease of "power2". That's impossible if you animate the entire "transform" value. 

I wonder if you were trying to do this(?): 

See the Pen abXrRmO?editors=0010 by GreenSock (@GreenSock) on CodePen

[skiller]

Hey there,

 

thanks for the fix! Now at least it's behaving as before.

 

The reason I resorted to using a matrix was that while in the project it seemed the only way that worked consistently across different browsers and OSes.

 

You know, sometimes when you're bogged down in work, the deadline is approaching fast and you (as the last link in the food chain) have far too little time, you forfeit the elegant solution in favour of the one you know that works, and defer the elegant solution towards the phase when you actually have time to spend on exploration. Haven't we all been there?

I can't really remember whether my problems with the suggested approach came from 3.12.3 (since noticed the newer version only later in the process), but in the meantime I figured I could alleviate some of the problems I ran into while animating clip masks with the common approach of using functions as parameter values, as suggested in the best practices and mentioned in the “common pitfalls” section of the GSAP website. I had the problem that I had to have a possibly resizing container in mind, and that using scalar values  sort of froze the GSAP animation state calculated at the beginning of the page's lifetime – and something along the line of x: () => myValue alleviated that. But that is, as you know, a wholly different task and problem (but it might have irritated and destracted me and weakend my already insomnia-affected GSAP problem solving skills).

 

So yes, the suggested solution is neat and nice, the bug in version 3.12.3 is gone in the next one, and I'm a happy camper!

 

Thanks a bunch and best regards

Constantin

[GreenSock]

5 hours ago, skiller said:

The reason I resorted to using a matrix was that while in the project it seemed the only way that worked consistently across different browsers and OSes.

I'd strongly recommend always setting transform-related values via GSAP because it protects you from a lot of that stuff (browser irregularities). For example, GSAP applies transforms on SVG elements via the "transform" attribute rather than a CSS property because it's more consistent. Safari had problems unless it was done that way in certain scenarios. And if you have BOTH a CSS value AND a transform attribute applied, some browsers might prioritize the CSS one, and others prioritize the CSS one. 

 

In short, GSAP specializes in transforms, making each individual component independently animatable, cross-browser compatible, and performant. 

 

5 hours ago, skiller said:

I had the problem that I had to have a possibly resizing container in mind, and that using scalar values  sort of froze the GSAP animation state calculated at the beginning of the page's lifetime – and something along the line of x: () => myValue alleviated that.

If you're having any trouble like that, we'd be happy to take a peek at that and offer some advice. I can't imagine why resizing a container would "freeze" GSAP animation(s). 

 

I'll be pushing the 3.12.4 update live very soon. Again, I apologize for the confusion/hassle with that regression.