Jump to content
Search Community

GreenSock last won the day on April 21

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    23,135
  • Joined

  • Last visited

  • Days Won

    817

Everything posted by GreenSock

  1. Great catch, Blake! There was a one-letter typo Should be fixed in the upcoming release. There's the same method on CSSPlugin as well, so here's an updated TweenMax with that: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js The colorStringFilter() isn't generally intended for public use (which is why it's undocumented, but I exposed it on purpose as a static method just in case it came in handy down the road for someone and I could be like "just use this method..."), but it basically lets you pass in a 2-element array with a starting string and an ending string, and it'll search both of them for colors and harmonize their formatting (rgba() unless there's one that's hsl-based, in which case it'll switch to hsla()). That's useful for the core engine because the "animate any string" stuff taps into that. Otherwise, colors inside the strings like "red" or "#F00" or "#FF0000" wouldn't map to numbers that can be tweened. Make sense? If you're asking because you're working on the TypeScript definitions, I'm inclined to leave that colorStringFilter() undocumented. Feel free to push back if you think it's important to have in there.
  2. GreenSock

    GSAP Docset for Dash?

    We actually reached out to the Dash folks (or person) and were told that it's strictly a "the more people request it, the more likely it'll get done" thing over there, and he said GSAP wasn't toward the top of that list so it may never happen (well, unless a bunch of people start telling Dash they need GSAP in there). We're not really interested in open-sourcing all the guts of our docs at this point, no. Sorry. But if we did that, how exactly would that help? Would you be looking to program some kind of scraper to grab the necessary data and shove it into a Dash-specific format? Just curious.
  3. Thanks for offering folks around here a free pro account, @mspanish. Very kind of you. And good luck with the product.
  4. Ah, okay, I see what you're talking about. Yes, minimumMovement was designed for regular x/y drags (total pixel movement), not rotational dragging. However, I think it's a good idea to add that capability, so I'll do so in the upcoming release which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js (uncompressed). That'll interpret minimumMovement as degrees when used with type:"rotation". That should make it very simple for you. In the mean time, if you want a solution with the current version, here's an example of using onPress and onDrag to limit dragging until a threshold of 45 degrees is reached: Does that help?
  5. Hm, I didn't quite understand that last response - did you still have a question we could help with? Have you looked into ScrollMagic? I think that's built to handle things like this. We didn't author that tool, but it uses GSAP under the hood for the animations, so it should be relatively easy for you to tap into
  6. A timeline's duration is solely dependent on its child animations (it's like a wrapper). So yeah, you could just decide that your timeline is gonna be 100 (or 10 or whatever) seconds long and do the math to figure out where to place things percentage-wise. var totalDuration = 100; tl.add(myTween, totalDuration * 0.25); //25% But of course that assumes you'll make sure that it's populated in a way that actually makes it 100 seconds long. So, for example, if your last animation that you put in is 2 seconds long, you'd need to place it at 98 (because 98+2 = 100). Also keep in mind that every animation has a progress() method, so you can easily jump to 25%, for example, like: tl.progress(0.25); Does that help at all?
  7. Sure, as long as: You leave the GSAP files untouched (with copyright and license notices) You make it clear (in your Readme?) that the GSAP files are subject to their own license and were not authored by you. You try to keep those files reasonably up to date. You don't include any of the bonus members-only plugins like MorphSVGPlugin, SplitText, etc. But you might want to consider just having your users get GSAP themselves so that they're more likely to get the latest files and you don't have to mess with updating stuff frequently. That's up to you, though. It's an honor to have you using GSAP in your project(s).
  8. I don't have time to rewrite your code right now, but I think the problem is that you wrote it in a way that depends on reading/writing the actual values that you're animating from within the loop (like, each iteration of the loop depends on the animation having already completed and altered the values). I think it'd be much better to just maintain the destination values as their own separate properties or variables or something. For example, instead of reading eleB.getAttribute("x"), you'd track the destination values like eleB.destX. That's also make things faster and cleaner, since you don't have to constantly be converting them from strings to numbers. And then you'd still animate the "real" values/attributes in your tweens - you'd just be keeping the destination values separate. Does that help at all?
  9. Sure, this is a great case for a function that'd let you parameterize stuff however you want. For example: function hops(target, iterations) { var tl = new TimelineLite(); for (var i = 0; i < iterations; i++) { tl.to(target, 0.75, {left:"+=100", ease:Back.easeOut.config(4)}, 2 * i) } return tl; } hops("#logo", 5); Notice you can use relative values, like left:"+=100" so that each time it's jumping ahead 100 from whatever it is when that tween starts. Does that help?
  10. When I created that ease, it was basically trial-and-error. I visualized the portions that needed to go slower/faster and just tweaked the curve accordingly and tried it out. Copy-and-paste the values from the ease visualizer (the code at the bottom, just the numeric values for the CustomEase). That's all that needs to change. If you have a demo with the new sizes, we can take a peek, but yeah, that's the general idea (trial and error). There's probably some mathematic way of figuring it out, but I don't have the time to invest in that at the moment
  11. It sounds like you solved the issue yourself, right? I just wanted to make sure.
  12. You didn't really set it up for touch events. But I know, it's a little confusing and complex. Touch events are very different, and you've also gotta consider how the various browsers implement them (Android and Apple use TouchEvents, but Microsoft uses PointerEvents). I don't have time to go into all the specifics but I'd recommend Googling about the differences. To make your demo work on iOS or Android for just one touch, you could just put this at the very top of your getMouseSVG() function: //if it's a touch device, grab the first changed touch event because that's what has the clientX/clientY values if (e.changedTouches) { e = e.changedTouches[0]; } Here's one link you might want to read: https://developers.google.com/web/fundamentals/design-and-ui/input/touch/ Again, that code I gave you above isn't intended to be a bulletproof solution for every browser and all multi-touch scenarios - I just wanted to get you going in the right direction Happy tweening!
  13. I'm not familiar with AMP at all, but from the links you sent it definitely looks limiting/restrictive. Pretty uncomfortable for an animator. I wish I could answer your question but you probably need to ask the AMP folks. Have you tried that?
  14. Yep, Blake's link has all the info. To answer you directly: TweenMax.set(".div:nth-child(1)", {top: "50%", left: "50%", yPercent:-50, y:10}); Notice I added y:10 which would move it down by 10px. Is that what you were looking for?
  15. For the record, if your goal is to get a percentage-based translation, you should use xPercent and yPercent: TweenMax.set(".div:nth-child(1)", {top: "50%", left: "50%", yPercent:-50}); It's much faster and more reliable than passing in "transform" strings which, when reported back by the browser, are converted to px (that's a browser thing, not GSAP). If you're still having trouble, a codepen demo would be super helpful. Cheers!
  16. I don't have much time at the moment, but my guess is that the problem may be in your mouse/touch handling. It looks like you're only accommodating mouse events, not touch (hence the problem only showing up on mobile). And in your handlers, you're expecting the event to have clientX/clientY properties but touch events are different, thus those would be null. Have you tested to see what values you're passing into the tweens? That'd be my recommendation. If you want it to work well on mobile, it'd be a good idea to code with touch events in mind (in addition to mouse events of course). Also, I'd update to the latest version of GSAP (1.20.2 right now).
  17. Glad you got it sorted out. Yes, "x" and "y" are short for "translateX()" and "translateY()" (transforms), thus they're relative to the objects original position in the document flow. A negative value is totally normal if you're moving up and to the left. Cheers!
  18. Percentage-based width/heights on line attributes weren't supported...but I just added support now. Here's a file you can try on codepen: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/DrawSVGPlugin.min.js Better? Once you confirm, I can drop that into the official downloads.
  19. Yep, that was intentional. Sorry if it was confusing. The context menu would actually cause problems in several scenarios (like long-taps on mobile devices, etc.). Most people didn't want it (from what we heard at least). You should be able to enable it by setting allowContextMenu:true on your Draggable config object. Does that help?
  20. Yeah, I was scratching my head for a bit too, @OSUblake. Totally non-intuitive (at least to my brain).
  21. Interestingly, that's natural phenomena when you scale things like that. Even though GSAP is animating the scale perfectly linearly, it appears to kinda slow down at the end because the pixels on the outer edges are moving away from the center faster. You can see this more clearly by using a single tween and extending the duration to 5 and make it scale to something really big, like scale:30. Notice what happens toward the end - things appear to slow down, but if you console.log() the scale, you'll see that GSAP is animating the values correctly. I'm sure there's a good math solution and I don't have time to research it at the moment, but I crafted a CustomEase that gives better results: CustomEase.create("zoom", "M0,0,C0.41,0.33,0.708,0.57,1,1"); Here's a fork: If you want to tweak the ease, just go to: https://greensock.com/ease-visualizer?CustomEase=M0,0,C0.41,0.33,0.708,0.57,1,1 Does that help?
  22. GreenSock

    Hue value

    They're definitely using canvas, though I don't have time to dig into all the source code and decipher how they're doing the color. Have you tried starting with a grayscale image and applying colorize or hue to that?
  23. Hm, I don't think I've ever heard of getBoundingClientRect() being wrong most of the time - it has always worked flawlessly for me in every browser, so I'm really curious. Do you have an example that shows it being inaccurate? I wonder if perhaps you're misunderstanding what it's supposed to return?
  24. Remember that technically, when you set/animate css properties, they must leverage CSSPlugin and wrapped in a css:{} object so that GSAP understands where to funnel that stuff. Years ago, since it was so common for people to animate CSS properties, we added convenience behavior to the core that checks to see if the target is a DOM element, and if so, it'll automatically do that wrapping for you on your object. In other words, if you pass in an object like this: {x:100, y:200} GSAP will convert that to: {css:{x:100, y:200}} It does that on the original object for performance and memory reasons. So in your demo, you're trying to re-use the same objects over and over again which is typically fine, but in this case you're feeding them into a bezier tween as well which doesn't expect that type of formatting. In other words: //bad bezier:[{css:{x:100, y:200}}, {css:{x:300, y:100}}, ...] //good bezier:[{x:100, y:200}, {x:300, y:100}, ...] The solution is to just use fresh objects in your set() call in your loop: TweenMax.set(blueDot.target, {x:pointObjects[i].x, y:pointObjects[i].y}); Here's a fork: Better?
×
×
  • Create New...