Gabriel
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Everything posted by Gabriel
-
Say you want to tween an element from point A to Z over 10 seconds on a new timeline, but want to stop that tween 5 seconds into the timeline, so that the result is more like a tween from A to M over 5 seconds, but following it's A to Z path over 10 seconds. Any way to kill an element's property tween at a specific point in a timeline?
-
Thanks. I'll wait, setting rotation first works for now
-
top/left, animating an image... I'll have to get back to you on that
-
Oh, and while I remember, I noticed that the auto rotate feature of the bezier plugin wouldn't work until I set {rotation:0} on the elements first. Not sure of this was a bug. Cheers
-
Thanks for all the explanations. I kind of feel bad that I'm taking up so much of your time that you could spend on more productive ventures. I agree with you completely in terms of performance, and I'm fully understanding you. And I agree gsap performs as desired for common use cases. I wouldn't want to change this default behavior, especially as you've explained it. I do believe a future "clear/forget element" function would be a good addition, and would also add that this is kind of what I'd expect clearProps to do. But I understand that's a cssPlugin feature, so it affects the scope of that plugin, but would expect a tweenlite counterpart. Someone recognized the need for it, so it's a matter of consistency. But personally I don't even need it, as you've given me plenty of information to create it myself, thanks. I know my needs might not seem common, but I assure you they're practical. I'm not sure if you understood what I'm doing. For a casual javascript user who wants to make a banner animation using CSS transforms, gsap makes it a breeze with entry level skills. But doing a fullscreen animation on a responsive width website becomes a maze of calculations on top of calculations to give a consistent look. This is the problem I'm solving. You just wrap your a-z animation in a function using a simple API for creating any dom element using relative sizing and placement, and the plugin automatically handles resizing it so it's identical at any size, with the added benefit of cool out of the box animations included. Recreating the timeline is simple and fast, but recreating the dom elements on each resize would be horribly slow, therefore I have to recycle and reset those elements. Hence, this is a very practical use case. Thanks for all the help, I got what I need to finish it
-
I think this is perhaps a difference in thinking from an animation platform born in flash to animating a website. In flash I would expect gsap to maintain constant control, but with dom elements there are so many things happening between animations, and gsap can't be there every step of the way
-
Thank you for that in depth explanation. I had no idea that gsap was attaching information to my elements that wasn't visible to me in firebug. Since this data is attached to the dom elements themselves, is it correct that it persists when the timeline is killed? I mean, it's used internally for tracking properties in gsap and isn't actually used by the browser (the browser uses "transform"), so I guess it's confused why the information would stay attached after it's no longer needed. It seems if you kill all tweens on an object and time passes by, then gsap would have to recreate this tracking data based on the object's new position, because it can't be assumed that it's css and transforms haven't changed. Wouldn't manually changing an element's rotation, inline or by changing it's class style, therefore screw up gsap's ability to animate it? It sounds like deleting this object is my best option, because I'm trying to create a wrapper for recreating the timeline whenever the browser is resized, and I don't want the user to have to have to use a series of fromTo's or set's to account for the plugin's behavior. They should only need focus on creating a simple a-z timeline, and let the plugin handle the resizing functionality automagicaly. Even performing set on each element beforehand is not an option, as all elements won't pass through the constructor, and there's no point between element creation and timeline insertion for the plugin to hook into. It's still odd to me though. I understand why you say this object is created and it's purpose, but this isn't the only instance I'm needing to revert an element to be animated again later from a different location. The website is fluid/responsive, with many animated transitions, and browser resizing should not break any of these animations. So in my mind, what I'm doing seems common place stuff for a website like this. Releasing an element from memory seems an easier step than relying on fromTo's for fluid inline elements. Is there any plans to add a function to automate this? You could say, a "forget" function? I'm surprised I haven't seen this documented either, unless I missed something
-
Not really. I thought clear() is supposed to empty the whole timeline, and either using clearProps or clearing the style attributes would remove any changes to the elements. Where is _gsTransform even stored? The timeline or tween instance? And doing this for potentially thousands of elements in a loop seems inefficient. So I'm stuck trying to completely revert the timeline to an empty state without destroying it so it can be reused, and removing any changes to any elements. This seems like such a simple thing, I'm perplexed why this seems so complicated
-
What kills me is that I have a much larger animation and much more robust version of the tool in that codepen. With text, images, tons of layers, complex animations, and the tools to manipulate them easily... After the resize, just about the whole animation seems to look fine, except the layer rotation no longer works, but everything else looks fine! I hope someone can spot a problem...
-
OK, here's one of the kinds of problems I'm having. I can't figure out where to begin testing, because I'm not sure what's causing the problem. I trimmed out most of the fat out of this codepen, the non-related stuff. It creates the animation which works fine, but then when it clears it and rebuilds it using the same function it did the first time, suddenly it doesn't want to work. I set a timer to change the size after 5 seconds, to show before and after. After resizing, you can notice right away that it's no longer tweening the rotation: http://codepen.io/seraphzz/pen/FdhGg I've been scratching my head at this for hours. Everything works as far as I can tell. I'm going to redo some of the stuff, like using an object rather than a switch, but despite some cosmetics everything seems to work fine, even on my much larger animation. Just, not after rebuilding though, and I don't see why.
-
Yeah, that's a handy feature. It's ideal for setting inline values to their prior values. I never noticed it since it's buried in the CSSPlugin documentation. Thanks, I'll have use for it later. Although for my banner animation, attr('style','') will work, and is about 10% faster after testing, but that's a special case scenario with potentially thousands of elements. Although, It would be handy to be able to use clearProps on a timeline and have it reset all it's animation targets for convenience. Personally, I think it's logical to add it as a flag for .kill(). When you want to destroy an animation after you're done with it, it makes sense that you may want to throw out the baby with the bath water and return everything to the pre-animation state, to kill any changes that were made as well. Yeah, when I get back to that part I'll have to see if I can reproduce it in a Codepen. I have to focus on one thing at a time for now, so I'll get back to you on that. Thanks
-
Actually, I just solved the last mentioned problem. obj.attr('style','') will do the trick. ALTHOUGH.... Shouldn't GSAP be able to handle this? (it stores prior values afterall)
-
At the moment I'm trying to build a resizing tool for a banner animation. The animation contains hundreds of elements, created with jQuery on the fly. So after a screen resize, it's very costly to remove all the elements and remake them again with new dimensions. So the idea is: I changed my building function to not create new elements if they already exist, using ID's and a counter to check. But my building function still set's their dimensions and positioning by swapping the existing element into the same function in place of a newly created element. So, to resize: resize(width,height,callback,tl) Which will seek(0) the animation to reset everything, empty the timeline, resize the container, run the callback which rebuilds the animation, and then play it from it's prior playhead position. BUT: it's not working at all. If I pause it before rebuilding, and inspect the elements in Firebug, they are littered with transforms even after doing seek(0). So playing it runs a new animation on pre-transformed elements, and it's a big mess. I can't seem to reset the damn things. And I'm assuming that it's because the FROM tweens are immediateRender:true, so after doing a seek(0), they are immediately in their "from" positions. I need immediateRender:true set, it's not an option to turn it off. So how can I put the elements back in place without destroying and rebuilding?
-
Yeah it does. Nice pun, lol. Pretty much how I would expect it to work. I guess I was more interested in the aspect of resetting tweens to their starting point. I haven't set up any definitive tests to isolate the problem, but I was having some problems prior with pausing a timeline who's tweens were in a container with "display:none" set. I thought I read somewhere that GSAP wouldn't animate non-displayed tweens, but Firebug showed them tweening away in the background. When I'd display the container, the animation would be running fine, from whatever point in the timeline it had reached. But whenever I'd pause the timeline and then tl.seek(0) or tl.play(0), the element positioning would become all screwy and wouldn't animate properly when it started playing again after displaying it. So that's related because I was working on a way to destroy and rebuild the timeline each time I displayed the container, so positioning would be correct. Seek wasn't doing the job for me for resetting the original element positions, so I'm exploring solutions I'm also getting three different animation results for FF/chrome/IE when it comes with dealing with display:none issues, for this animation and others. For some transitional animations, I'm grabbing coordinates for beginning/ending positions by toggling display:none/block back and forth, and animating things into place. It's only working right in FF, chrome and IE both are giving me issues. But I haven't even began to look into debugging those animations yet. To explain what I mean by transitional animations: For example, the page footer is always displayed, and it's position is dictated by page elements above it, because it's in the flow. If I'd like to display a hidden element above it, it would be nice to animate the footer going to the new position first, and then animate the div from a height of zero, growing downward to meet the footer. To get the new footer position on any given page, I have to toggle the hidden element display on and off before animating. I'm actually working on much more complex transitional animations, but I'm only getting good results in FF so far, with IE amazingly doing better than Chrome. But unless this rings a bell for you, I'll have to get back to you later with more specifics, or a Codepen or something
-
Could someone explain the difference between using kill() or clear() on a timeline? That is, besides kill() being able to kill individual tweens, lets assume we're using kill() on the entire timeline itself. The documentation is unclear (use kill to kill a tween; define kill?). If they're the same, then why use clear(), other than the timeline instance being preserved? And, I'm interested if either resets the positions of elements in a timeline to their beginning position, or what the best way to go about that is? Thanks!
-
So with a FROM tween, immediateRender doesn't change a thing, whether true or false....
-
Please read my last message carefully. I noted that immediateRender:false works correctly on 'TimelineMax.to' tweens. As a side note, I made the argument for the developers that the duration should not change the behavior. My argument stands, even if this is 'expected' behavior. Second, please read my 2nd to last message carefully. Even if an object is not set as 'hidden' initially, and you tween it FROM a 'hidden' state, a "TimelineMax.from" tween will NOT render it immediately 'hidden' when using a zero duration. Even when explicitly setting immediateRender:true. And it behaves this way with other properties.
-
And "timeline.to" is performing the exact same behavior, not applying on the first loop the same as the second loop. immediateRender:false fixes it in this case. Although IMHO, it should default to false. It should behave the same whether you use 0 or 1 for the durations, and shouldn't drastically alter it's behavior based on the duration used. This is not consistent at all.
-
It's not acting the way you claim. Yes, "timeline.from" tweens render immediately, that 'is' the behavior I want. And when I substitute the 0 duration with say, 0.001, then the animation runs exactly the way I want and expect. But, if the duration is 0, then on the first loop of a repeating timeline, it is NOT rendering immediately. So, If I want to animate tl.from(img,0,{opacity:0}), the image will be visible for the entire first loop, and then go hidden and work as expected for the second loop, so first loop !== second loop. My functions are too big and interconnected to paste here, and a codepen to explain the simple concept of what I'm doing would take too long. It's very simple. I have a banner animation: <div id="banner"> <div id="layer1">stuff</div> <div id="layer2">stuff</div> <div id="layer2">stuff</div> </div> The goal is to, very simply, swap the layers in sequence during the timeline. Now, instead of simple swaps, I have animations. One layer may slide left, another fade into view, etc. And to facilitate this, I've made a function that is like: function(timeline,delay,{oldLayer transition args},oldLayerAnimationDuration, {newLayer transition args},newLayerAnimationDuration,animationsOffset) So, as you can see, you just plug in the values you want. If you want the old layer to slide left, but want the new layer to immediately pop into view, then you should be able to put in a zero duration for newLayerAnimationDuration, which would use a from tween to put it into view. If you used a fade animation, then it would be animating from a 0 opacity. So, in conclusion, 'from' tweens are broken when you use a 0 duration, regardless of how you set immediateRender. It's not providing the consistent behavior one would expect, leading to a need for coding hacks for when someone comes along and uses zero for an argument.
-
I'm trying to build a dynamic animation function that swaps two div's using different transition effects. The idea is to tl.to the old div out of the way, and tl.from the new div into place. But because of this behavior, it can't handle tweening the new div when I use a zero duration. The only workaround is bloating my code to add a zero duration specific exception using: tl.to(obj.css('opacity',0),0,{opacity:1, immediateRender:false}) Which means not using tl.from and setting it to zero opacity first, and only when zero is passed as the duration. Either that or parsing zero durations as 0.001
-
I'm still encountering inexplicable behavior. Here's a different example: var text = some text object var img = some image object var tl = new TimelineMax(repeat:-1) tl.to(text,3,{left:500}) tl.from(img,0,{opacity:0}) On the first loop, 'img' will be visible the entire sequence. But on the next loop, 'img' won't be visible and will appear after 'text' animates, as expected. Each loop should be the same, but the first loop is different than the rest. I'm encountering all kinds of problems with zero duration timeline tweens, I think something is buggy.
-
Besides convenience, it should be implied that if you have an element positioned 'left', and you desire to animate it's 'right' property, that 'left' should be unset. It doesn't make sense to animate a property that would yield no effect, and that you'd need to manually unset the conflicting property. Same with 'top' and 'bottom'.
-
You're awesome. I wasn't sure if it was intentional behavior, so this helps a lot. Thanks Just noticed my strange typo in the headline, lol, oh well.
-
Using TimelineMax and TweenMax, when doing a zero duration tween to adjust an object's visibility at a point on a timeline, the visibility is toggled immediately instead of in sequence. Example var text = some text object var img = some image object img.css('visibility','hidden') var tl = new TimelineMax() tl.to(text,3,{left:500}) tl.to(img,0,{visibility:'visible'}) tl.from(img,3,{left:500}) The image object will be visible at the start of the timeline animation, instead of after the text object animation. Although it works if you do: tl.to(img,0.001,{visibility:'visible'})
-
TweenMax.to(status,1,{boxShadow:'0px 0px 1px 1px blue', yoyo:true, repeat:-1}) $(window).mousedown(function(){ TweenMax.fromTo(status,1,{backgroundColor:'green', boxShadow:'none'},{boxShadow:'0px 0px 1px 1px green', yoyo:true, repeat:-1}) }) $(window).mouseup(function(){ TweenMax.fromTo(status,1,{backgroundColor:'blue', boxShadow:'none'},{boxShadow:'0px 0px 1px 1px blue', yoyo:true, repeat:-1}) }) This works. A lot less code and more logical, and probably what I was looking form. When trying to use .fromTo() before, I should have set boxShadow to 'none', I didn't realize it would create overlapping shadows. This doesn't require keeping extra tweens in memory either, which should be more efficient. Thanks for responding guys
