Jump to content
Search Community

GreenSock last won the day on March 24

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    23,069
  • Joined

  • Last visited

  • Days Won

    815

Everything posted by GreenSock

  1. I'm a little confused about this "lag" you're talking about that doesn't exist in TweenMax but does in TimelineMax - can you show me an example? Those tools have the same logic applied internally. And by the way, I assume that "lag" simply has to do with the time between when a tween/timeline ends, and when you are manually restarting/reversing it which isn't a bug at all. And actually, a lot of work went into making sure that none of those lags ever happen inside repeat cycles of a TimelineMax or TweenMax (I think every other engine I've seen uses logic that permits that lag - GSAP is the only one that protects against it). If you need to manually do the restart/reverse, there are ways you can do it that won't permit any gap between frames, but it'd really help to see an reduced test case from you so that I'm sure we're talking about the same thing.
  2. Sorry, we don't offer different easing for different properties inside the same tween. There are two reasons for that: Performance. The rendering loop is probably the single most important thing to optimize and the ease is an essential part of that. Being able to calculate the ease ratio once and use it for all the properties makes things very efficient. If we were to offer individual tweening, we would lose the ability to optimize that way which in my opinion would be a big loss. GSAP places a HUGE priority on performance, as you know. API complexity You're welcome to build a plugin if you want, but that plugin would have to do a lot of work quite frankly, as it'd need to kill off all the other property tweens so that it could handle them all internally (in the plugin). For example, if that tween is handling x, y, width, and height, then you'd need to have the plugin kill all of those in the parent tween, and then create and manage them inside the plugin. I really think it's a much better idea to just create a separate tween for properties that need to be eased differently.
  3. Yes, according to my tests both of those are fixed in 1.18.4 - you can test it yourself by just linking to https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js for TweenMax. Sorry about the glitch in 1.18.3. As for when we'll release 1.18.4, probably within the next few days. You're welcome to just revert to using 1.18.2 or use the preview of 1.18.4 (just don't link directly to that beta URL - download it, minify it, and use it on your server).
  4. I believe that had to do with a minor bug in 1.18.3 which will be fixed in 1.18.4. You can preview it (uncompressed) here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js.
  5. No, sorry, irregular collision detection is not something GSAP handles.
  6. No, but: You can just loop through the array that's returned by TweenMax.staggerTo() and set each duration() to whatever you want. You can cycle "delay" values
  7. I'll add support for 2-part borderBottomLeftRadius, borderBottomRightRadius, borderTopLeftRadius, and borderTopRightRadius values in the upcoming 1.18.4 release which you can preview (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js. Better?
  8. Ah, yes, I hadn't anticipated a particular use case (which obviously you're employing). Sorry about that - it should be resolved in the upcoming 1.18.4 release which you can preview (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js. Better?
  9. Great, thanks for letting us know. Happy tweening!
  10. Sorry about that 1.18.3 regression - it should be resolved in the upcoming 1.18.4 release which you can preview (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js. Better?
  11. I believe this is resolved in the upcoming 0.14.6 release which you can preview (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js. Better?
  12. You could certainly create your own ease function if you prefer, or use something like Blake's implementation (http://codepen.io/osublake/pen/OyPGEo/). We do have it on our roadmap to offer a CustomEase tool but we have a few other things ahead of it in the pipeline and can't really guarantee any specific delivery date yet. Happy tweening!
  13. Nice work, Michael! Seemed silky smooth to me.
  14. Yep, that should be resolved (the NaN). Please let me know if you find any other issues.
  15. Just a random idea (if you need to use PNG): what if you just put the <img> into a <div> that has a background-color? And obviously size the <div> to exactly the size of your image. That way, the transparent areas would just show through to the background-color.
  16. Sorry, but we never intended to expose methods like that or commit to BezierPlugin supporting things like getting the length, etc. We have limited resources to dedicate to our free forums and aren't in a position to start supporting this type of functionality and consulting. I wish I had an easy answer for you. If you'd like to contact us about our consulting services, we can certainly explore that with you.
  17. You can attach files by clicking the "more reply options" button below. And make sure you zip your fla before posting (for security reasons). I wonder if maybe you have a filter applied to your object which forces pixel snapping (cacheAsBitmap) in Flash (which has nothing to do with GSAP). To get around that, you could try nesting your object inside another one, thus you're animating an element that doesn't have cacheAsBitmap turned on, but I'm not 100% sure that'll solve things for you (I haven't worked in Flash for years). The TransformMatrixPlugin solution was intended for rotation.
  18. This should be resolved in 1.18.3 (just released).
  19. By the way, we made some improvements and released 1.18.3 which handles this better right out-of-the-box.
  20. @expint2006, that's correct - since Adobe Animate exports to canvas, those plugins wouldn't be useful. It's kinda like trying to apply font-size to text inside a JPEG image. MorphSVGPlugin and DrawSVGPlugin both animate SVG shapes; they can't target a bunch of pixels in a canvas. It's a fundamentally different technology. ScrambleTextPlugin works with DOM elements that contain real text, so it won't be relevant either. If there's enough demand, perhaps we'll create special plugins specifically for Adobe Animate that might accomplish similar feats.
  21. Sounds like G.tiles is spitting back something that's not valid. Are you sure it's a DOM element? Maybe add a console.log(G.tiles) just above that line to see what's being returned. Tough to troubleshoot blind - if you provide a reduced test case in codepen, we'd be happy to take a peek.
  22. Are you looking for this?: http://greensock.com/asdocs/com/greensock/plugins/BezierPlugin.html#bezierThrough() We completely rewrote the entire BezierPlugin at some point and it's orders of magnitude better in various ways - I wonder if you're using an old one from before that rewrite. I believe the old one used "soft" for everything. I think "prepend" optionally lets you pass an object in that should be placed first in the list of points (unlikely you'd need that).
  23. Also, be mindful about how many pixels you're pushing around the screen at any given time; typically in cases like this the biggest bottleneck BY FAR is the graphics rendering which the browser is responsible for, thus it has nothing to do with GSAP (or even CSS animations). So, for example, GSAP might do all of its work and only sip 1% of the CPU, but then the browser might take 99% to calculate all the individual pixels and paint them to the screen. If you keep the area of change as small as possible (visually), you'll get better results. From your codepen, it looks like you're basically making the browser repaint the entire screen (all the pixels) constantly during the animation which might be fine on beefier mobile devices and desktops, but it certainly explains why you might see poor performance on low-end mobile devices with limited processing power.
  24. I'm pretty sure it's not really a "bug" per se, but I can see why you might think it was. To clarify, the tween that was getting killed by the overwrite was essentially "propping it open", meaning it was the determiner of the duration of the timeline (since it was last). Thus when it was killed, the timeline resized which forced the playhead to move (since the playhead cannot be positioned beyond the end of the timeline). Let's say the timeline rendered at 0.41 seconds which tripped the call() at 0.4 which triggered the overwrite which killed the tween that made the timeline 0.5 seconds long, so now it's 0.4 seconds long (that's where the call() is). So technically the playhead was forced to move back from 0.41 to 0.4 in this case, meaning it needed to re-render. Again, I wouldn't consider that a bug but how that you understand the mechanics hopefully it's easy to adjust for and get the behavior you want (probably by setting overwrite:false, although there are other ways).
×
×
  • Create New...