agamemnus

http://greensock.com/docs/#/HTML5/GSAP/TweenMax/killChildTweensOf/ It seems to be killing descendants (in the example), not just the children. Children are commonly known as only the immediate descendants.

http://greensock.com/forums/topic/11270-how-do-i-kill-a-timeline-correctly/

Oh.. thanks, guys! I appreciate the help, and the library. One more bug quashed.

So I have...: var timeline = new TimelineLite () Then timeline.from a few times, and timeline.fromTo once, and timeline.to once. Each one has {onUpdate: onUpdate ..}. In the onUpdate, I run TweenMax.killTweensOf(timeline) if certain conditions are met. I logged it and it's run hundreds of times, but the timeline keeps going. What's up with that? Anything obvious I missed? (I'd rather not post my code...)

Yes to all. So yes, texture memory on phones is small compared to PCs. Combine CSS stuff with canvas webgl stuff and it gets smaller... I can't really give you any specific examples except for my game (which I'd rather not mention here right now) which can crash on lower-end phones due to low texture memory. The other issue is that texture-composited sections look blurry compared to non-composited sections... @Jonathan: I will see if adding perspective helps negate some blurriness...

I do not think it should be a default -- texture memory can be a precious thing. Besides, things can look bad if they were all textures. Being able to set a default for new animations, though, is a good idea. I would, however, support trying to make these trigger that, because they do with plain CSS: 1) "transform: 'translate3d(0, 0, 0)'" -- without killing Greensock specific sub-transforms (or vice-versa) in the process. 2) "{x: 0, y: 0, z: 0}" -- one of these needs a small value to make the 3D texturing work...

Thanks.

Ok. I am using: "{x: 0, y: 0, z: .001}" to replace "translate3d(0, 0, 0)"... is there a way I can trigger this without using a low z value?

It hit me. Like a freight train hitting a brick. I have a .rotation property which interferes with GSAP rotation. Don't you think it might be a better idea to contain all the properties in a specific gsap object in order to prevent these collisions???

I have the same problem with 180 and 360. Terrible and strange rotation effects in both Firefox and Chrome. I couldn't use "rotation". I don't know why -- code below. "rotation" simply doesn't work... I'm using the "robust" version, 1.14.2. I resorted to converting final_rotation to 179.9 or 359.9. TweenMax.to (current_wheel, 1.5, { ease : Linear.easeOut, rotation : final_rotation, onComplete : animation_complete })

P.S.: is there a global setting for this we can do?

Thanks! Actually I only need to set this once per game... but resetting the game doesn't reset this effect.

No man, I don't want to use GSAP for that. I would like to set the style myself. I want GSAP to not set webkit-transform when I tell it to only set transform. Is that possible?

Ok, I see what is happening. I set transform to scale, not webkit-transform. However, TweenMax is setting both, and my reset statement is not resetting webkit-transform. Is there a flag I can set to prevent this hidden backwards-compatibility? I understand you want to have backwards compatibility, but to hide it is not the right way.

Jonathan: the second time it runs, nothing happens... even in your version. Edit: but it looks like you put the "set" in the wrong place. Your version does run it twice if set is inside the setTimeout function, but why isn't mine running twice?

Using the CDN.

I did do some tests... The slowdown only happens in Chrome. I made a very simple test case of the GSAP animation and it was perfectly smooth, but on my real case it isn't. The difference is that in the real case there are more layers of parent / ancestor elements for the target element. The element was relatively positioned. Changing it to an absolutely positioned element made the effect much smoother... I think that in Chrome, there are some superfluous miniscule repositioning calculations being done, and maybe constant reflows. Chrome tends to do more anti-aliasing than Firefox (and thus reflows more, I guess). I tried disabling requestAnimationFrame as well as replacing the tween with code from two other animation libraries, and the smoothness difference on relative versus absolute positioning were the same.

I see. Well that does not say what it does with the non-CSS elements, is placed way below the first example, and is wayyyyyyyyyyy too long. Here is what I would write.. or something like this: Even if it's rare to do this (a question mark on that..), it's extremely frustrating when your tween doesn't seem to work for no reason!

When I look at the docs, the most obvious page is http://greensock.com/docs/#/HTML5/GSAP/TweenMax/ or TweenLite -- not the CSSPlugin page. The TweenMax minified file does have the CSSPlugin code, so it would be helpful to note this potential issue on the TweenMax page, next to the examples.

Hi, Take a look at this: http://jsfiddle.net/agamemnus/hp4h9g42/ If I don't wrap "left" and "top" in the "css" object, GSAP will think I am trying to tween my object's left and top (non-DOM!) properties. The docs for TweenLite/TweenMax need to give out a warning for such cases, or possibly this is a bug with the library.

Ok. I just read this: http://greensock.com/forums/topic/7996-engine-update-frequency/ So apparently I am just seeing things, or maybe using the wrong tween.

Hi. I just started using GSAP earlier today. Very nice. I'm having a little trouble though and most of the links on google are dead (probably because you updated your site a few days ago). I have an animation that reduces the size of an element, but it looks jittery because the first few frames seem to happen without much smoothing. When it gets small, it is smooth, but not when it is large. Is there any way I can control the amount of frames per second in my tween?