Jump to content

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

GreenSock last won the day on July 24 2019

GreenSock had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


Community Answers

  1. GreenSock's post in Draggable - .css('transform') returning different values in IE than Chrome/Firefox was marked as the answer   
    If you're using GSAP to do the y-translation anyway, it'd be a lot easier to just tap into the _gsTransform on the element, like:
    yourElement._gsTransform.y; That's where the values are cached.
    And if you're trying to figure out the y position of the Draggable's target, did you know that the Draggable instance has a "y" property as well? So you could just tap into that. Example:
    Draggable.create("#id", {   onDrag:function() {         console.log(this.y);   } }); Does that help at all?
  2. GreenSock's post in No entrys in console - morphSVG - precompile and shapeIndex: 'log' was marked as the answer   
    Ah, that's because you're not using <path> elements. Those are much more flexible. The easy fix would be to convert your <polyline>/<polygon> elements to <path> elements which is super easy with:
    MorphSVGPlugin.convertToPath("polygon, polyline"); Does that help? Sorry about any confusion there. I've added a note to the docs now. 
  3. GreenSock's post in Problem when tweening both rotation and position around svgOrigin was marked as the answer   
    SVG1 doesn't work the way you expect because transforms in GSAP are always applied in a very consistent order, and rotation comes before x/y translation. 
    Here's a fork with a 3rd option that does the math for you with some easy variables you can tweak (like centerX, centerY, radius, angle, etc.):
    That's a bit more complicated code, but it saves you from having to nest things (fewer elements for the DOM to manage). Is that what you were looking for? It basically figures out the angle and radius and you can animate those on a proxy object and use an onUpdate to apply the values appropriately. 
    Happy tweening!
  4. GreenSock's post in Draggable top/left in pixel and percentage was marked as the answer   
    Draggable wasn't really built do use percentage-based top/left values, but you should be able to manually translate things like this: 
    Does that help? 
  5. GreenSock's post in kill all tweens of an element was marked as the answer   
    The problem isn't the kill() - it's just the fact that you seek(0) which renders the timeline at a particular state and if you kill a tween, it doesn't suddenly force the target to revert to a different state. For example, if you tween opacity from 0 to 1 and then you rewind that tween, opacity will be 0. Then if you kill() that tween and drop another one into the timeline, opacity is still 0, thus it LOOKS like the tween didn't get killed but it did. 
    One solution would be to just reset the styles that you edited, like:
    Does that help?
  6. GreenSock's post in Looping draggable that snaps without throwProps was marked as the answer   
    Sorry for the late response - is this what you're looking for?:
    It limits things to one position left/right. I also reworked some of the logic so that it handles resizes of the window appropriately (well, you could certainly enhance it further, but the basics are there). 
    Does that help?
  7. GreenSock's post in dynamic timeline position was marked as the answer   
    Wouldn't it just be:
    var stagger = 0.1; //seconds between start times DOMS.each(function(index) {    tl.add(abc.xyz(DOMS[index]), index * stagger); }); Also, are you familiar with the staggerTo()/staggerFrom()/staggerFromTo() methods? For example: https://greensock.com/docs/#/HTML5/GSAP/TimelineLite/staggerTo/
  8. GreenSock's post in Transform merge bug was marked as the answer   
    Very interesting indeed. Here's what I discovered...
    It is indeed a browser bug, unrelated to GSAP. In fact, different bugs for Chrome/Safari than Firefox/IE/Edge You can see it by adding this to the top of your codepen (even without any GSAP code): var bug = document.querySelector(".dropdown-content--bug"); var cs = window.getComputedStyle(bug); console.log(cs.transform); //in Chrome/Safari, it's "none" (wrong), and in Firefox/IE/Edge, it's "matrix(0.5, 0, 0, 0.5, 0, -7.5)" (also wrong - notice the x-translation is gone) It has to do with the fact that you've got display:none on that element. Browsers tend to choke on that because the element isn't being rendered at all, thus its geometry isn't in the pipeline to report accurately (well, that's my assumption). So when GSAP asks "okay, what's the current transform", it's getting bad data from the browser. If instead of toggling display:none/block, you did visibility:hidden/visible, it resolves things in Webkit browsers...but not the others. In Firefox/IE/Edge, they'll actually report the transforms even with display:none EXCEPT percentage-based values! So your translate(-50%, 7.5px) becomes translate(0, 7.5px). Well, it's reported as a matrix() but it's basically the same thing.  We implemented a workaround a while back in GSAP for the display:none glitch that assumed it'd report "none" or a standard matrix in this condition but now Firefox/IE/Edge are doing this hybrid "kinda right, but not with percentages" thing, it failed that test internally (for performance reasons, we were skipping all that detection if the reported matrix wasn't "none" or an identity matrix). Looks like we'll have to remove that assumption now and run the logic regardless. In that condition, it has to toggle the display to block, get the computed style, and flip back again (all internally). Bummer. I've implemented that change in the upcoming release which you can preview (uncompressed) at:
    So basically, the moral of the story is that this issue is related to multiple browser bugs and inconsistencies, but GSAP has your back and you won't need to worry about it in the future
  9. GreenSock's post in stroke-linecap and drawSVG issue in IE11 and Edge was marked as the answer   
    Great catch, Craig. Gotta love those Microsoft browsers
    Here's what I discovered:
    You’re right - GSAP is animating things properly but the browser just isn’t rendering the changes to the screen.  If stroke-linecap is “round” and you ALSO set stroke-linejoin to “round”, it fixes things.  Changing the stroke-miterlimit or stroke-width will also trigger a repaint (meaning it’d have to change on every tick). That’s why things worked when you animated the strokeWidth.  It’ll also trigger a repaint if you set the “d” attribute of the path (even if you set it to its current value). However, that strikes me as likely not optimal performance-wise because it’d have to parse all the data again on every tick… Since plenty of people won’t know to do any of the above, I added some code to DrawSVGPlugin to sense if it’s a Microsoft Edge browser (and the linecap and line join meet the conditions above), it’ll automatically add a strokeMiterlimit:“+=0.0001” tween internally. This should be imperceptible but effective. I hate animating properties that the developer didn’t specifically request, but in this edge case (get it “Edge” case??), it seems like it’s a decent solution that won’t cause too many problems for people. I can’t imagine folks will get bent out of shape by 0.0001.  I have updated the bonus zip downloads as well as the codepen-specific one. 
    There are plenty of tutorials online and open source libraries that help people create the "progressive drawing" effect, but I don't think any of them address all these cross-browser quirks. Hopefully this is the type of "automatic" workaround DrawSVGPlugin now delivers that makes it worth the price of the membership. There are probably 4 or more odd browser inconsistencies that DrawSVG fixes for you too.
    Happy tweening!
  10. GreenSock's post in SVG scale transform tween doesn't work was marked as the answer   
    Yes, that's correct - GSAP parses matrix() and translate() values in the transform attribute but in order to accommodate more than that (like scale(), rotate(), etc.), it'd take significantly more code and bloat CSSPlugin which didn't seem wise since this is such an edge case and typically easy to work around. We strongly recommend always setting transform-related values through GSAP because it internally caches them and manages each component (scale, x, y, rotation, skew, etc.) much more cleanly.
    Is there any particular reason you need to have a scale() embedded inside the transform attribute itself rather than either setting it via GSAP or using a matrix()? (Most drawing programs I've seen generate code that uses either matrix() or translate()). 
  11. GreenSock's post in A clarification of TweenMax, TimelineLite, TimelineMax, etc, please was marked as the answer   
    I'm not sure I understand your question accurately, but maybe it'll help to understand the evolution...
    Everything in GSAP is object-oriented so each tween is an object itself. That's why you can control individual tweens with methods like restart(), seek(), etc.
    There are "static" methods which are attached directly to the class itself, like TweenMax.to() which is just a convenience we provide for creating a tween:
    //these all do the same thing (but the first just assign the tween to a variable) var tween = new TweenMax(...); var tween = TweenMax.to(...); TweenMax.to(...); Without the static methods, your code would be a tad longer, and people would feel like they have to maintain references as variables (which aren't necessary at all, and could even prevent GC). Again, it's about convenience for you as the developer, and keeping your code clean. 
    At first, there was only TweenMax.to()/from() but it quickly became clear that it'd be really nice to have a stagger method that create a bunch of to() (or from()) tweens for you, with just staggered timing. So we added TweenMax.staggerTo(). Great.
    Then, we created TimelineLite and TimelineMax which are simply containers for tweens (and other timelines). But every animation ultimately boils down to a tween instance (TweenLite or TweenMax). That's what populates timelines. So to get them in there, we had the add() instance method:
    timeline.add(tween, time) timeline.add(tween, time) ... But that's annoying to type it all out, like:
    timeline.add( TweenLite.to(...), time) Notice that you're having to type "TweenLite.to(" a lot, so we added convenience methods to the timeline classes that just make your code cleaner:
    //OLD timeline.add( TweenLite.to(...), time); //NEW timeline.to(..., time) The old way still totally works - we just provided a new, more convenient way to do exactly the same thing. 
    The same goes for staggers:
    //OLD timeline.add( TweenMax.staggerTo(...), time); //NEW timeline.staggerTo(..., time); If you're asking why we don't have static TimlineLite.staggerTo() methods, it's because:
    Timelines by their very nature are very instance-specific. When you're adding tweens to a timeline, you've gotta be specific about which instance you're talking about. Thus, it's not very helpful to have static methods which are not instance-specific. It'd clutter the API unnecessarily.  It'd require a lot of typing. tl.staggerTo() is much easier than TimelineLite.staggerTo() Does that answer your question? Again, I have a sneaking suspicion that I didn't understand your question properly. 
  12. GreenSock's post in Repeat all animation one time was marked as the answer   
    By the way, you might want to use timelines all the time because they can be so powerful for this type of thing. Here's a comparison of your old code and what the new one could look like in timeline form. Notice I'm using labels (which you can name more intuitively) and relative timing so that you can very easily tweak the timing and everything adjusts automatically. For example, make the middle section take 1 second longer by adjusting where that label is and BOOM, everything after that gets pushed back too. 
    //OLD TweenMax.to(logo,0,{delay:0,alpha:0}); TweenMax.to(logo,1,{delay:1,alpha:1}); TweenMax.to(bot1,1,{delay:3.5,y:"400px",ease: Power2.easeOut}); TweenMax.to(top1,1,{delay:3.5,y:"-400px",ease: Power2.easeOut}); TweenMax.to(top2,1,{delay:6,y:"-400px",ease:Power2.easeOut}); TweenMax.to(bot2,1,{delay:6,y:"400px",ease:Power2.easeOut}); TweenMax.to(textefin,1,{delay:0,alpha:0}); TweenMax.to(textefin,1,{delay:7,alpha:1}); TweenMax.to(cta,1,{delay:0,alpha:0}); TweenMax.to(cta,1,{delay:10,alpha:1}); //NEW TweenMax.set([textefin, cta], {opacity:0}); //initial state var tl = new TimelineMax({repeat:1}); tl.fromTo(logo, 1, {opacity:0}, {opacity:1}})   .addLabel("scene2", "+=2.5")   .to(bot1, 1, {y:400, ease:Power2.easeOut}, "scene2")   .to(top1, 1, {y:-400, ease:Power2.easeOut}, "scene2")   .addLabel("scene3", "+=1.5")   .to(top2, 1, {y:-400, ease:Power2.easeOut}, "scene3")   .to(bot2, 1, {y:400, ease:Power2.easeOut}, "scene3")   .addLabel("scene4")   .to(textefin, 1, {opacity:1})   .addLabel("final", "+=2")   .to(cta, 1, {opacity:1}); You'd also get random access to the whole timeline, so you can jump to any spot like tl.seek(3) or you can hook it up to a slider or repeat it a certain number of times.
    Happy tweening!
  13. GreenSock's post in Two calls to seek produce different results was marked as the answer   
    Sorry about that. I believe I found the issue and the ONLY time you'd run into it is if you have a fromTo() tween with immediateRender:false and you put the playhead directly on top of the starting time and THEN somewhere before it (very rare). One of the optimizations we make internally is to skip rendering in cases when the requested render time is identical to the the current time that's reflected. In other words, if a tween renders at a time of 0 and then later it's asked to render at a time of 0, it should be like "hey, I'm already at 0...I don't need to do anything, so I won't chew up CPU cycles needlessly".
    In this particular scenario, you've got it rendering at a time of 0 exactly, and then when you move the playhead backwards, technically the tween is still being asked to render at 0 (you can't have a negative time) - that's why it skipped that render. But the "from" part needed to revert in your case. It's a tricky scenario because fromTo() tweens with immediateRender:false have 3 unique states - the "from", the "to" and the "before from" part.
    I've added some code to the next release that should resolve that particular scenario. You can preview it (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js
    To be clear, it would have worked if you put the playhead anywhere else except directly on top of the start time, like seek(0.401) instead of seek(0.4) in your example. 
    Sorry about any confusion there. Thanks for letting us know about it. 
  14. GreenSock's post in Nested Timelines competing? was marked as the answer   
    That's just because any animation can only have ONE parent. Kinda like a DOM node - it can only exist in one place in the tree structure. There are many reasons for this (I'll spare you unless you request an explanation). So basically you nested the child in one timeline, but then when you nested it in the 2nd, it removed it from the first. Everything seems to be working exactly as it should. 
    You could accomplish your goal with a little trickery - you could create a tween of that timeline (the one you originally nested...the child), and nest that tween. Think of it kinda like an instruction set to move the playhead on that animation. So you can just create a new tween instance each time you need to nest it - they'd all control the playhead of that [formerly child] animation. 
    Here's a fork that shows it in action: 
    Notice I switched to using TimelineMax because it has a tweenFromTo() method, but you could just use TimelineLite and create a raw tween like TweenLite.to(child, child.duration(), {time:child.duration(), ease:Linear.easeNone}) and nest that. 
    Does that clear things up? 
  15. GreenSock's post in Modifiers Plugin snaps to X value instead of tweening was marked as the answer   
    It's just a logic thing in your code - I think this is what you meant in your modifier function: 
    return (animContainer === animContainerR) ? window.innerWidth - animContainerL._gsTransform.x : value; You're trying to mirror based on the position of animContainerL, not that new (reflected) value. And you don't do window.innerWidth - value because "value" would be based on the reflected position. Example: if the window is 1000px wide and the left position is at 400, the right one would be at 600 but then on that next tween, "value" would be totally different between the two elements (400 vs 600 to start), thus you 1000 - 600 = 400 on the first render (wrong). 
    There are many ways you could do this - it just made the most sense in my brain to base it off the position of the one on the left and reflect it. 
    Does that help?
  16. GreenSock's post in Intermediate matrix was marked as the answer   
    Can you help us understand your goal? Why are the matrix values useful to you? 
    You can snag them from the string at element.style.transform. Typically it's easiest to use a RegExp to isolate the numbers. But again, I think it'd be super helpful if you gave us a little more insight about the "why" behind the request. 
    Also keep in mind that 3D matrices have 16 values whereas 2D ones have 6. 
    And yeah, Shaun is exactly right.  
  17. GreenSock's post in scale not updating on Class instantiated object was marked as the answer   
    I read your description and code a few times and I'm still a bit lost, but here's my crack at a simplified (and more performant) version: 
    Is that the effect you're after? 
    By the way, one of the problems with your original example was that you were tweening to scale:null and backgroundColor:null which are both invalid values. 
  18. GreenSock's post in Duplicate a timeline was marked as the answer   
    Here's a version that I think gives the effect you wanted:
    I just looped through the elements and created a timeline for each. I also wanted to make sure the velocity didn't change when it goes vertically, so I added some math for that (relatively simple). It just affects the duration. 
    var el = $(".element"); var width = $(".container").width() - el.width(); var height = $(".container").height() - el.height(); var velocity = 600; //pixels per second var spacing = 0.12; var horizontalDuration = width / velocity; var verticalDuration = height / velocity; el.each(function(i) {   var tl = new TimelineMax({repeat:-1, delay:i * spacing});   tl.to(this, horizontalDuration, {x:width})    .to(this, verticalDuration, {y:height})    .to(this, horizontalDuration, {x:0})    .to(this, verticalDuration, {y:0}); }); Does that help?
  19. GreenSock's post in DrawSVG not animating - SVG issue or brain issue? was marked as the answer   
    There are a couple of issues:
    The percentages refer to the starting and ending points of where the stroke is drawn, so "100% 100%" would literally have no length at all. I think you meant "0% 100%" DrawSVGPlugin is for animating the **stroke** of an SVG path/element, but it looks like you've got just a filled path. That won't work. If I understand your goal correctly, you'd need to animate a mask. Like maybe draw a stroked path over the top of your letters/signature and use DrawSVG to animate the stroke and use that as a mask (and of course make sure the stroke-width is thick enough). Not trivial, but probably doable. I think we've had a few other threads about this type of effect here in the forums like https://greensock.com/forums/topic/15868-animate-a-handwritten-signature/ Happy tweening!
  20. GreenSock's post in Don't use reserved properties! was marked as the answer   
    As for immediateRender:false, it's only true by default in these cases:
    on a timeline.set() that's at the very beginning of a timeline (startTime:0). If it's anywhere else on the timeline, immediateRender will be false. any from() or fromTo() tweens on a loose (not timeline-based) set() call You should never have to set immediateRender:false on a to() tween. Ever. That's the default (well, unless the duration is 0 for obvious reasons).
    In practical usage, it should rarely be necessary to set immediateRender:false.
  21. GreenSock's post in SVG path animations messed up by UI tabs was marked as the answer   
    It looks like the problem is that when you introduce bootstrap, it's hiding the elements in a way that causes the browser to incorrectly report their dimensions via the standard getBBox() method that's common to all SVG elements. Here's an example you can drop into your code:
    console.log(document.getElementById("box").getBBox()); Notice that's returning x:0, y:0, width:0, height:0 which is why everything looks like its origin is in the top left corner. 
    The only solution I know of is to make sure your tweens start when the element is actually in the DOM and not display:none. 
  22. GreenSock's post in Performance of two timeline rather then one. was marked as the answer   
    Nah, performance-wise it's almost the same. I guess technically it's an extra function call if you nest it, but you'd never notice any real-world difference unless maybe you're nesting things hundreds of levels deep and there are thousands and thousands of simultaneous tweens. Actually, in some cases nesting can actually improve performance. 
    Happy tweening!
  23. GreenSock's post in Start new animation when one is completed was marked as the answer   
    If I understand your question properly, you could just have your turnButtonOn() and turnButtonOff() methods return tween/timeline instances so that you can easily sequence things in your customAnimation() method. For example:
    display = {   turnButtonOn: function() {     var tl = new TimelineLite();      //...add animations to tl...     return tl;   },   turnButtonOff: function() {     var tl = new TimelineLite();      //...add animations to tl...     return tl;   },   customAnimation: function() {     var tl = new TimelineLite();      tl.add(display.turnButtonOn())       .to(...).to(...) //add custom stuff       .add(display.turnButtonOff());     return tl;   } } Does that help?
  24. GreenSock's post in Jack Doyle will you please save Flash? was marked as the answer   
    I feel your pain. And I appreciate your kind words about GSAP. We lived in Flash every day for years and it still has a warm spot in my heart, but I haven't even opened it for months...probably over a year actually. 
    Part of me relishes the challenge of building a GreenSock-ified version of CreateJS and I absolutely see the value of having a GUI to drag stuff around on timelines. Certain animations can really benefit from that. But it's a HUGE undertaking to build from scratch. It's not something we have the resources to tackle at this point. 
    Grant Skinner (the main author of CreateJS) is a very skilled developer and I have lots of respect for him. 
    I think it'd be smart to have Adobe use GSAP as the runtime animation engine for whatever is build in the IDE, but I'm sure that's not a simple undertaking for them to rip out the current guts and swap in GSAP. Then again, maybe it's not that hard. I don't know, but if it's something you wish Adobe would do, I'd encourage you to tell them. Sometimes I get the impression that it's hard for the big software companies to really understand what the market wants when they've got a lot of momentum internally going toward certain feature sets they decided were important. That's not a criticism of Adobe - I'm just saying it's probably hard for them to know unless they hear from a lot of developers. Make your voice heard. 
    We did briefly chat about the GSAP+Adobe combo with them years ago and they've always been very kind but it just didn't fit into their roadmap at that time. Maybe they'll reconsider at some point, and we'd certainly be open to chatting again, but their cooperation would be essential for something like this to get off the ground. We can't just hook into their IDE and make it spit out a GSAP-ified version of all the animations. Even if we figured out a way to do that today (without their help), they could release an update next week that breaks everything we did. That's why it's so critical to have a solid commitment from them and plenty of cooperation. 
    In the mean time, I bet that most of the things you build visually in Flash could be accomplished in GSAP raw in the browser without depending on Flash at all. Yes, it'd take a little time for you to get up to speed on the API and how to build your stuff in HTML/CSS, but most people I've talked to who took the plunge tell me that they now LOVE it and would never want to go back, much like @Vitality said above. 
    Thanks again for taking the time to share your idea/suggestion. I really wish I could snap my fingers and make this happen.
  25. GreenSock's post in Animation - Syntax Error- Unexpected token ) was marked as the answer   
    Looks like the very last line is missing a }