RolandSoos

Thank you, it's great news!

Does the license allow to use custom builds of GSAP? For example, if I do not need the CSSPlugin, am I allowed to build GSAP without it and use it in end product? In the license I think this point is related, but I'm not sure how to interpret "for your own use" and "originally intended". I'm sure this is not originally intended C. You may make modifications to the source code exclusively for your own use in order to perform bug fixes or other minor edits required to operate the PROGRAM as originally intended.

I was able to find what I needed. I know how GSAP animates the attributes. If I made animated data to look like attributes for GSAP, then I can use the getAttribute/setAttribute methods of the object. class HelloWorld { constructor() { this._abc = {}; } getAttribute(key) { if (this._abc[key] === undefined) { this._abc[key] = 0; } return this._abc[key]; } setAttribute(key, value) { this._abc[key] = value; } } var obj = new HelloWorld(); gsap.to(obj, 0.4, { attr: { a: 5, k: 10, z: -5 }, onUpdate() { console.log( obj._abc.a)}

Thank you, but I think it is not the right solution for me. In this case GSAP alerts on the console that I use invalid property and your solution only works if the initial value is 0: That would not work for this one: class HelloWorld{ constructor(){ this._abc = { } } getData(key){ if(this._abc[key] === undefined){ this._abc[key] = 2; } return this._abc[key]; } setData(key, value){ this._abc[key] = value; } } var obj = new HelloWorld; gsap.to(obj, 0.4, { a: 5, k: 10, z: -5 });

I have an object which has a getter and a setter function. I would like to force GSAP to animate any unknown property through these getter/setter functions of the object. Is it possible? I know GSAP can animate object's properties, but that means that the possible keys must be defined before GSAP can use it. What I want is similar how GSAP can animate any attribute names or CSS variables. Proxy might be the right solution, but maybe GSAP has such feature out of the box: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy E

Yes, I totally understand these aspects. So I'm not sure what could be the solution I'm struggling to optimize the page load which contains several animated elements. On emulated 4x CPU slowdown the site takes 4 seconds until LCP, but 25-30% (1-1.5 sec) used for GSAP to create the timelines. I was only able to optimize one thing in my code: adding display:none or not-attached dom elements to the timeline hugely slowing down the processing as GSAP display them or attach to the dom to be able to use getcomputed style, which cause multiple style recalculation and layout.

I have another idea. A cache method in GSAP which could provide the required values what normally red from getComputedStyle. gsap.cache("h1", { opacity: 1 }); gsap.set("h1", { opacity: 0.5 }); gsap.cache("p", { transform: none }); gsap.set("p", { x: 100 }); gsap.cache("#a", { transform: none, opacity: 1 }); gsap.fromTo("#a", 0.4, { opacity: 1, x: 0 }, { opacity: 0.5, x: 100 }); The flow is (when all required values are provided in the cache method) h1: Read opacity from [cache] h1: Render opacity p: Read and prepare transform from [cache] p: rende

@GreenSock I have a theory which creates two pipelines: one for property initialization/reading and one for rendering. So if I have the following: gsap.set("h1", { opacity: 0.5 }); gsap.set("p", { x: 100 }); gsap.fromTo("#a", 0.4, { opacity: 1, x: 0 }, { opacity: 0.5, x: 100 }); The current flow is: h1: Read opacity [might have style recalculation] h1: Render opacity p: Read and prepare transform cache [style recalculation + layout <- caused by opacity change] p: render transform #a: Read opacity [style recalculation <- caused by t

I was able to find the root cause of those layout processings. It seems like changing the opacity schedules a layout. So when I set the opacity on an element the next _parseTransform will recalculate style and layout instead of only recalculate style. https://codepen.io/mm00/pen/vYyNOpV

Thank you Jack! One interesting addition for this topic. Just added some measurement codes to GSAP: _getComputedProperty = (target, property, skipPrefixFallback) => { console.time(property); let cs = getComputedStyle(target); const ret = cs[property] || cs.getPropertyValue(property.replace(_capsExp, "-$1").toLowerCase()) || cs.getPropertyValue(property) || (!skipPrefixFallback && _getComputedProperty(target, _checkPropPrefix(property) || property, 1)) || ""; //css variables may not need caps swapped out for dashes and lowercase. console.timeEnd(property); return

Thank you for the detailed explanation! That isn't true actually. The transform property contains data for ALL of the following: x, y, z, rotation, rotationX, rotationY, scaleX, scaleY, skewX, skewY, plus it has to handle the transform-origin ... I expressed myself badly, I know GSAP handles all of those. I wanted to tell that in my usage I know every property which is animated and they are set in the same tween, also I know that their pre-tween value is on specs default. This is why I could build a startValue cache with those values to prevent .getComputedStyle().

Yes, this happens only on the first change. But if you have an animation on page load, it is important to be performant and there is no space for not-needed processing. It is good to know that .fromTo() is slower than .to(). I had an assumption that .fromTo() should be faster as GSAP do not need to read anything from the element itself. All the data available locally. The following code contains the suggested gsap.set() before tweening. As you mentioned it will still cause a _parseTransform(). Well, it is really seems unnecessary to parse the previous transform as it wi

I'm trying to optimize things in my application. I use the tool in Chrome Dev tools -> Performance -> Record What I see that I have a fromTo GSAP animation which animates only one property for example "x". At the start of the animations GSAP reads the previously applied transform probably to maintain other at the original value, but this cause a recalculate style in special circumstances. I would like to tell GSAP that it does not need to read the previously set transforms, just overwrite every transform value with the one set in this tween. Do you have any suggestion wh

I think I was able to find the right solution in the forum:

Hi, I would like to migrate my custom GSAP V2 plugins to V3. Do you have documentation about plugin structure for V3? Could you point me in the right direction? I used overwriteProps in V2 to define custom properties. Here is how my plugin looked like for V2: var _div = document.createElement("div"), _filterProp = /Edge\/\d./i.test(navigator.userAgent) ? false : (_div.style.filter !== undefined) ? "filter" : (_div.style.webkitFilter !== undefined) ? "webkitFilter" : false, _filterCSSProp = _filterProp ? (_filterProp == 'filter' ? _filterProp