Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Friebel

Using smoothOrigin in gsap.defaults() method throws warning/error (v3)

Recommended Posts

Using the smoothOrigin parameter in the gsap.defaults method (gsap v3.1.1) throws an error in the console:

gsap-core.js:83 Invalid property smoothOrigin set to false Missing plugin? gsap.registerPlugin()

 

These are my defaults:

gsap.defaults({
     overwrite: 'auto',
     smoothOrigin: false,
});

 

I tried this with and without importing and registering the CSSPlugin, but there's no difference.

 

Inside both the migration guide as well as the docs on CSSPlugin I see 'smoothOrigin' written like that. And I even copied the exact property just to be sure I didn't have a typo. But it doesn't matter, the error persist.

 

I also tested the defaultSmoothOrigin property of the CSSPlugin directly. Setting the defaultSmoothOrigin property directly in the CSSPlugin doesn't throw an error, so at first glance it looks like that works, but that's because Javascript is just adding defaultSmoothOrigin as a new property to the CSSPlugin object there, as I can't find any 'defaultSmoothOrigin' property inside the CSSPlugin code and when printing CSSPlugin.defaultSmoothOrigin to the console without setting it the console shows 'undefined'.

So this doesn't seem to work either:

CSSPlugin.defaultSmoothOrigin = false;

 

So somehow the gsap defaults() method doesn't seem to recognise the smoothOrigin property and the CSSPlugin.defaultSmoothOrigin property seems to be unavailable. Is this perhaps a known issue of the latest version, or inside the documentation and migration guide? or am I missing something here?

 

https://greensock.com/docs/v3/GSAP/CorePlugins/CSSPlugin

 

Share this post


Link to post
Share on other sites

What kind of object are you trying to tween? Defaults gets applied to every tween, kind of like if you were using Object.assign. 

 

var defaults = {
  smoothOrigin: false
};

var obj = {
  x: 100
};

gsap.to(obj, Object.assign(defaults, { x: 200 })); // => Invalid property smoothOrigin

 

smoothOrigin should only be valid on DOM elements.

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, OSUblake said:

What kind of object are you trying to tween? Defaults gets applied to every tween, kind of like if you were using Object.assign. 

smoothOrigin should only be valid on DOM elements.

 

I tween SVG/DOM elements in this case and use the documented general gsap.defaults() method. And as I wrote above, also tested this directly within the CSSPlugin (so also general/global), as written in the CSSPlugin documention.

 

This is the documentation on defaults in the migration guide and I do exactly that:

 smoothorigin-docs-defaults.thumb.jpg.9b9063fc5405f59c7ebeedd6d4b201d4.jpg

 

 

And this is the documentation on the CSSPlugin, and I tested exactly that:

smoothorigin-docs-cssplugin.jpg.03a8741ef6c9d4cf5e1594770c735d40.jpg

 

In this project I'm only having tweens on SVG/DOM elements. But there are places in this project where I tween on arrays of SVG/DOM elements with .to() which should also work (and I see it working, except for the origin problems I'm facing right now, which perhaps is related?) and always worked like that in v1 and v2. This is a project that's running for years now and kept up to date ever since, but somehow after only upgrading to gsap 3 (and adjusting all syntax to gsap 3) is having this issue.

 

Arrays are allowed as target elements in version 3 still though, according to https://greensock.com/docs/v3/GSAP/gsap.to():

image.png.1d7034e107910d5565b34c5d3378366e.png

 

So maybe gsap is trying here to apply the defaults object to an array here and throws an error because an array is not an object in Javascript?

 

I do some more testing

 

 

 

 

Share this post


Link to post
Share on other sites
44 minutes ago, Friebel said:

And as I wrote above, also tested this directly within the CSSPlugin (so also general/global), as written in the CSSPlugin documention.

 

I don't think that CSSPlugin documentation hasn't been completely updated for v3. This won't work anymore.

CSSPlugin.defaultSmoothOrigin = false;

 

45 minutes ago, Friebel said:

So maybe gsap is trying here to apply the defaults object to an array here and throws an error because an array is not an object in Javascript?

 

It seems to work fine here with an array and NodeList.

 

See the Pen eb7d255fc4cd5192ba43326111b64847 by osublake (@osublake) on CodePen

 

 

46 minutes ago, Friebel said:

origin problems I'm facing right now, which perhaps is related?

 

What origin problems are you having? Are you sure that you want smoothOrigin to be false? That will make it jump.

 

Can you make a demo showing some of these problems?

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, OSUblake said:

What origin problems are you having?

 

Or are you talking about the origin problems in your Draggable question earlier?

Share this post


Link to post
Share on other sites
12 minutes ago, OSUblake said:

Or are you talking about the origin problems in your Draggable question earlier?

The Draggable issue I had in the other thread is solved with the preview of the latest Draggable (3.2.0) which fixed the issue.

 

The origin problem I'm facing now is in the same project as that Draggable thing, but there's no issue on the origin problem of the <g> that's being rotated with Draggable, but with some other elements. That said, they are inside that <g> so it could be Draggable related.

 

Since v3 these objects all have a different offset (SVG), which I had calculated and set with transformOrigin and worked fine in v2. So I figured maybe that smoothOrigin has something to do with it, because some default, calculation or setting obviously has changed in version 3 causing this different behaviour. There's something off with the origin now and this isn't a browser thing, as the previous version (working with gsap v2) still works fine.

Share this post


Link to post
Share on other sites

[also see my post before thisone, two posts in a row, but can't add these quotes to my previous post]

 

57 minutes ago, OSUblake said:

I don't think that CSSPlugin documentation hasn't been completely updated for v3. This won't work anymore.

It's starting to look like it, although I would not expect that from Greensock and it's also written in the v3 Migration guide.

 

57 minutes ago, OSUblake said:

It seems to work fine here with an array and NodeList.

Thanks for helping by testing this. I'm using SVG btw and the group these objects are in (<g>) are also being used by Draggable to rotate everything around by the user interaction.  So it looks like Draggable v3 is doing something different then Draggable v2 with the orientation/origins, or gsap in general handles origins (on svg) differently, or some setting is there now I don't know about (or it still has something to do with the smoothOrigin thing)?

 

[edit] Disabling everything Draggable in the project is not solving the issue, so it looks like this is not Draggable related.

Share this post


Link to post
Share on other sites

It's hard to know what's going on in abstract like this. Can you please create a minimal demo exemplifying smoothOrigin not working?

Share this post


Link to post
Share on other sites
9 hours ago, Friebel said:

Since v3 these objects all have a different offset (SVG), which I had calculated and set with transformOrigin and worked fine in v2. So I figured maybe that smoothOrigin has something to do with it, because some default, calculation or setting obviously has changed in version 3 causing this different behaviour. There's something off with the origin now and this isn't a browser thing, as the previous version (working with gsap v2) still works fine.

I can't think of anything that's different in terms of transformOrigin. I just tested the smoothOrigin and I can't see any problems at all, so as @ZachSaucier suggested, it's be super helpful to see a reduced test case. 

 

9 hours ago, Friebel said:

So it looks like Draggable v3 is doing something different then Draggable v2 with the orientation/origins, or gsap in general handles origins (on svg) differently, or some setting is there now I don't know about (or it still has something to do with the smoothOrigin thing)?

No, not that I can think of. I'm sure a demo will help expose the problem so we're not just talking theoreticals. 

Share this post


Link to post
Share on other sites
12 hours ago, GreenSock said:

I can't think of anything that's different in terms of transformOrigin. I just tested the smoothOrigin and I can't see any problems at all, so as @ZachSaucier suggested, it's be super helpful to see a reduced test case. 

I am debugging this right now and tried to start with a simpler project myself, but I'm afraid this is a problem that's happening with several things stacked together, so first I try to debug this myself a little, because making a 'reduced test case' doesn't seem to do the trick here at this stage.

 

Findings I have so far:

1) In gsap v2 it was working to supply only one value to the transformOrigin property, like this: 

gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px` });

gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px` });

Not sure if that was a typo I created years ago which obviously worked in version 2 and so I never noticed this, or that this was supposed to work in version 2 as some kind of feature, but it's not working the same in version 3 anymore, so I changed this into having 2 variables:

gsap.set(this.p[0], { transformOrigin: `0 ${pointOriginTransform}px` });

 

2) It seems like gsap 3 is handling positioning of svg elements differently. Previously this was the calculation I had to set a transformOrigin: 

const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5;

But in version 3 this needed to be changed into:

const pointOriginTransform = wheelCenterY - pointCenterY; 

So it looks like gsap 3 is using the center of svg elements now and therefore I stripped the radius of the svg circle from the calculation in order to have the same result. So there is obviously something changed in gsap 3 according to transformOrigin vs version 2.

 

3) In the project I'm upgrading to gsap 3 now I use cloneNode to clone SVG nodes. In gsap version 2 I could set a transformOrigin with TweenLite.set() and after that clone that element and set a transform origin on the clone. And that worked fine when doing rotations after on both elements. But in gsap version 3 things don't work that way. So I needed to first clone the original element and only after that apply a transformOrigin to it. Or else the clone was somehow off in positioning/origin. As if gsap 3 is doing something destructive to the object where v2 was not or visa versa.

 

4) There is another problem I'm facing now, which seem to be related to rotating after setting a transformOrigin. The first time it works as exected (and as in version 2), but rotating again (in the same timeline) doesn't have the same results as in version 2. Sorry for being this vague, but I'm still investigating this.

 

I can't share the project I'm working on I'm afraid and will try to create a reduced project when I find a way, but so far it all seem to be related; the cloning, the hierarchy of the SVG (working inside groups) and maybe even the Draggable plugin controlling the main group. So first I do some more testing here. But if according to what I wrote above you have some clues or suggestions on things that are changed in v3, that would be appreciated!

 

Thanks again for your help.

Share this post


Link to post
Share on other sites
3 hours ago, Friebel said:

I changed this into having 2 variables

GSAP 3 stripped out a little bit of complex string parsing but most of it has been added back. I think this might be case where support should be added back? @GreenSock can give us his thoughts.

 

3 hours ago, Friebel said:

2) It seems like gsap 3 is handling positioning of svg elements differently.

I don't see this in testing. GSAP 3:

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

 

GSAP 2:

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

 

Can you please try to make a reduced test case of this?

 

3 hours ago, Friebel said:

So I needed to first clone the original element and only after that apply a transformOrigin to it. Or else the clone was somehow off in positioning/origin. As if gsap 3 is doing something destructive to the object where v2 was not or visa versa.

That doesn't make much sense - GSAP doesn't have a cloning method so I'm not sure how it could be related. Are you sure that it works differently than v2? Again, a minimal demo would be incredibly useful. Cloning an element with properties set via GSAP seems to work fine in my tests.

 

3 hours ago, Friebel said:

The first time it works as exected (and as in version 2), but rotating again (in the same timeline) doesn't have the same results as in version 2. Sorry for being this vague, but I'm still investigating this.

My only guess given the lack of details is that it could possibly be related to the change in the default overwrite value and the tweens are in conflict. The new default is false while the old one was "auto".

 

I hope you can get these issues sorted soon! We'd love to fix any bugs that exist, the sooner the better :) 

  • Like 1

Share this post


Link to post
Share on other sites
37 minutes ago, ZachSaucier said:

That doesn't make much sense - GSAP doesn't have a cloning method so I'm not sure how it could be related.

I know, but Javascript does: 

 

this.p[i] = this.p[0].cloneNode(false);

 

Share this post


Link to post
Share on other sites
3 minutes ago, Friebel said:

I know, but Javascript does

Right but how is GSAP related to affecting the properties of the cloned element in that case?

Share this post


Link to post
Share on other sites
4 minutes ago, ZachSaucier said:

Right but how is GSAP related to affecting the properties of the cloned element in that case?

If I knew that that might be an answer to solve this issue here, right? 😉

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Friebel said:

Not sure if that was a typo I created years ago which obviously worked in version 2 and so I never noticed this, or that this was supposed to work in version 2 as some kind of feature, but it's not working the same in version 3 anymore, so I changed this into having 2 variables:


gsap.set(this.p[0], { transformOrigin: `0 ${pointOriginTransform}px` });

 

Did you try it the other way.

gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px 0px` });

 

  • Like 1

Share this post


Link to post
Share on other sites

Most of what you said didn't make much sense to me (not that you didn't write clearly - I'm just saying that GSAP 3 didn't suddenly change to using the center of SVGs as the default transformOrigin or any of the other "changes" you noticed). Like Zach said, the only thing that sounds like it MAY be the cause of some confusion in your project is just the shift from overwrite: "auto" to overwrite: false but that'd only come into play if you wrote conflicting tweens originally. Plus it's easily "fixed" with gsap.defaults({overwrite: "auto"}). Does that resolve things in your project? 

 

And yes, transformOrigin is always supposed to have two values separated by a space. 

 

And no, GSAP doesn't do any cloning of nodes internally, nor does it do anything "destructive" that I can think of. 

 

6 hours ago, Friebel said:

2) It seems like gsap 3 is handling positioning of svg elements differently. Previously this was the calculation I had to set a transformOrigin: 


const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5;

But in version 3 this needed to be changed into:


const pointOriginTransform = wheelCenterY - pointCenterY; 

So it looks like gsap 3 is using the center of svg elements now and therefore I stripped the radius of the svg circle from the calculation in order to have the same result. So there is obviously something changed in gsap 3 according to transformOrigin vs version 2.

I'm super curious to see a demo of this. Can you please provide one that shows the different behavior in v2 vs v3? I can't reproduce any of this in GSAP 3, so I'm really struggling to figure out why you're experiencing that and I suspect there's something else at play in your app that's causing the problems but it's super difficult to troubleshoot blind. 

 

I know you said you'd work on a reduced test case. I sure appreciate your efforts in that regard, as I realize it takes some time. We can be patient. 

  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, OSUblake said:

 

Did you try it the other way.


gsap.set(this.p[0], { transformOrigin: `${pointOriginTransform}px 0px` });

 

Yes I tried that, but it wasn't necesary as the other way is the right way. Most of the steps in the animation now have the right locations after applying the change in calculation of that transformOrigin, which needed to be different in v3 than in v2.

So the solution was as I described above. Only problem left is that one tween in that timeline somehow doesn't have the exact right offset when using gsap v3. I'm debugging that right now.

Share this post


Link to post
Share on other sites
20 hours ago, GreenSock said:

Most of what you said didn't make much sense to me (not that you didn't write clearly - I'm just saying that GSAP 3 didn't suddenly change to using the center of SVGs as the default transformOrigin or any of the other "changes" you noticed).

Hello Jack, I understand that it doesn't make sense to you. If it would make sense to me I didn't have to open this thread, so we're on the same page ;)

Guess that's the life of a developer sometimes. Especially as a front-end developer.

WIth the change in my calculation of the transformOrigin I feed to the transformOrigin property, changing the one-value transformOrigin to a two-value transformOrigin and using the 3.2.0 version where the Draggable issue is fixed, the project is almost working as it was with v2. Except for one tween inside the timeline for some reason. There the offsets of objects are off. If I have thatone worked out, the animation is working with v3.

Share this post


Link to post
Share on other sites
21 hours ago, GreenSock said:

Like Zach said, the only thing that sounds like it MAY be the cause of some confusion in your project is just the shift from overwrite: "auto" to overwrite: false but that'd only come into play if you wrote conflicting tweens originally. Plus it's easily "fixed" with gsap.defaults({overwrite: "auto"}). Does that resolve things in your project? 

I tried it with setting the gsap.defaults({ overwrite: 'auto' })   (and also setting it to overwrite: false, just to have tested that, but both don't make any difference.

 

[edit] I have just narrowed the issue to the real issue here as it looks like: using transformOrigin on the original svg element (a circle) still needs the same calculation in v3 as in v2, so is unchanged. But after cloning that element with cloneNode(false) and setting transformOrigin on the clone (even when cloning before setting the transformOrigin to the original) has a different behaviour in v3 vs in v2. 

 

So for the original element needs to be set with 

const pointOriginTransform = wheelCenterY - pointCenterY + pointHeight * 0.5;

But the clones of that element (which I created before setting this transformOrigin) behave differently, eventhough they are appended to the same <g> and need to be set with:

const pointOriginTransform = wheelCenterY - pointCenterY; 

(So without adding the element's circle radius).

 

So for some reason there is a difference between the original element and the cloned element.

 

Share this post


Link to post
Share on other sites

Alright, everything is working now after in the end just a little change in the code to make it work with gsap 3. See conclusion below. BTW Having a single value in the transformOrigin property was a typo on my side I made when upgrading to version 3. So I did use two values in the original v2 version.

 

Conclusion after all this:

The transformOrigin needs to be set the same way in version 3 as in version 2. EXCEPT!!! When we clone a svg element with cloneNode(false) (and append it wo the same group as the original)!!! Than we need to set the transformOrigin specifically on the cloned objects too in gsap v3, which wasn't needed in version 2. But not only that, we have to set it to a different transformOrigin value;

transformOrigin on the original element (not the clone): 

transformOrigin: `50% ${pointOriginTransform + pointHeight * 0.5}px`

transformOrigin on the cloned element:

transformOrigin: `0 ${pointOriginTransform}px`

So the original element needs an offset of the radius of the circle, while the clone don't need that offset.

 

To me this means that a cloned element which has a transformOrigin set by gsap on the original element (a svg circle in this case) before cloning, but its clone doesn't have the (same) transformOrigin as the original element. Whereas in version 2 it did have the same transformOrigin in the clone as the original and was therefor a real clone. This issue is there both with using gsap 3.1.1 as well as using 3.2.0. 

 

Could it be that gsap 3 is keeping values like transformOrigin inside javascript objects instead of inside DOM object-attributes and therefore don't come with the clone and got calculated differently or not at all?

Anyway, this took me way too much time. And I have some more projects to upgrade, so glad this finally is working now.

  • Like 1

Share this post


Link to post
Share on other sites

Ah, this sounds like it's related to the fact that the smoothOrigin feature on SVG elements internally records the necessary offset values (to keep the origin-switching smooth) and that wasn't copied over when you cloned. In GSAP 2, I believe that was recorded as a data attribute on the SVG element itself but when rewriting GSAP 3 I didn't see the need for it and didn't want to waste the kb. I can see why that'd help in an edge case like this, though. Sorry about any confusion there. I'm sure we would have figured that out if we saw it in a reduced test case but I'm glad you've got everything working again (right?)

  • Like 2

Share this post


Link to post
Share on other sites
15 hours ago, GreenSock said:

Ah, this sounds like it's related to the fact that the smoothOrigin feature on SVG elements internally records the necessary offset values (to keep the origin-switching smooth) and that wasn't copied over when you cloned. In GSAP 2, I believe that was recorded as a data attribute on the SVG element itself but when rewriting GSAP 3 I didn't see the need for it and didn't want to waste the kb. I can see why that'd help in an edge case like this, though. Sorry about any confusion there. I'm sure we would have figured that out if we saw it in a reduced test case but I'm glad you've got everything working again (right?)

I think this explains why this issue occurred to a certain level. Great to know!

 

That said, as I wrote in another thread just now where I had an error-message in the Firefox console about 'oldParent' being null; I have some new findings according the above:

 

1) When settings transformOrigin with gsap.set() to a DOM object (which is in fact a clone of a SVG Circle DOM element, which IS on the DOM), but not appending it to the DOM before gsap.set(), the transformOrigin needs different values than when it IS appended to the DOM first.

In version 2 this wasn't the case, but in gsap 3 (probably because of the reason you wrote above), it is.

 

2) When using set() on a DOM element not being added to the DOM yet, when using gsap 3 there an error is raised by Firefox and the animation wouldn't load because it holds on that error. But other browsers seem to not having any issues with it and run. But the other browsers need to have a different value set for transformOrigin when not appended to the DOM though, as stated in point 1 above.

 

So conclusion to me here:

Gsap 2 somehow managed to set values with set() on a DOM element currently not connected to the DOM without problems. Even the transformOrigin values needed to be set the same as if the element was available in the DOM. But because of the inner workings of gsap 3 (origin-switching smooth?) we shouldn't use gsap set() and so on on DOM elements currently not available in the DOM as it is causing unexpected behaviour.

 

With adding the element to the DOM first and using set() after that that also solved the last bit I had in my previous conclusion:

In gsap 3 we still need to set the transformOrigin on the cloned element (so it's not being transfered over by cloning, as you also explained why), but we can now use the same transformOrigin values on the cloned element as on the original element (instead of needing to have a different value on the transformOrigin of a clone, as I needed to on the element not being on the DOM first).

 

Share this post


Link to post
Share on other sites

Related post that addresses this: 

 

Share this post


Link to post
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.

×