GreenSock
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Everything posted by GreenSock
-
Are you saying it doesn't work for you? Do you have a sample (codepen) that shows the issue?
-
Cycle "rotation" of element while animating a tween
GreenSock replied to Roman Kovalev's topic in GSAP
You mean something like this?: TweenMax.fromTo(".box", 2, {scale:1}, {scale:0.33, repeat:-1}); TweenMax.fromTo(".box", 0.5, {rotationX:0}, {rotationX:-90}); var shake = new TimelineMax({repeat:-1, yoyo:true, delay:0.5}); shake.fromTo(".box", 1, {rotationX:-90}, {rotationX:90, ease:Power1.easeInOut}); Obviously you can play with the timing and rotational values, but hopefully the concept is clear. I wasn't sure if you wanted it to keep looping either, so feel free to adjust the number of repeats. There are many ways you could organize this. -
Sure, that should be doable for the next release. For the record, the other reason we default to TweenLite is because it's very **slightly** faster performance-wise Though I doubt you'd notice unless you're literally tweening thousands of things simultaneously.
- 3 replies
-
- 2
-
-
- timelinemax
- tweenmax
- (and 2 more)
-
By the way, you don't necessarily need to use a Bezier to do this. If you just want a circular movement, you could use plain trigonometry math inside an onUpdate to apply things. Here's a fork of your demo that uses x/y transforms to do the positioning so that everything stays responsive too (resize the screen and things are still centered whereas in your other version, you were hard-coding values on "top" and "left" that would cause things to get out of whack when the window is resized): http://codepen.io/anon/pen/WxNZXO?editors=0010 I also removed the jQuery dependency. Is that what you're looking for? var radius = 200, items = document.querySelectorAll("nav .nav-item"), navTl = new TimelineMax(), spacing = Math.PI / (items.length - 1), i = items.length; navTl.staggerFromTo(items, 0.5, {scale: 0.5}, { x: -radius, scale: 1, opacity: 1, ease: Linear.easeNone, }, 0.5); while (--i > -1) { items[i].angle = Math.PI; //fabricating a custom "angle" property that we'll tween. navTl.fromTo(items[i], 0.5, { scale: 0.1 }, { angle: i * spacing + Math.PI, css: {scale: 1, opacity: 1}, ease: Linear.easeNone, onUpdate:applyAngle }); } function applyAngle() { TweenLite.set(this.target, { x: radius * Math.cos(this.target.angle), y: radius * Math.sin(this.target.angle) }); }
-
We received a few questions about this and apparently it was an issue in MailWasher itself and had nothing to do with the TweenMax file. See http://forum.firetrust.com/viewtopic.php?f=13&t=18829. It sounds like they already fixed it.
-
How to create CSS opacity gradient without darker lines / stripes effect?
GreenSock replied to galahad9gr's topic in GSAP
Hi galahad9gr. Welcome to the forums. We really try to keep these forums focused on GSAP-specific questions. It looks like your question is purely about CSS and you're not even using GSAP in that demo (although you're a Shockingly Green member, so clearly you're a GSAP person which is great!). I wish we had the resources to offer free consulting for all types of web development issues/questions, and perhaps someone here has the time and inclination to pitch in to help you (I hope so), but you might want to try a more appropriate venue like the CSS Tricks forums or Stack Overflow. The codepen you included seemed to be attempting to link to local images and style sheets and stuff, so you might want to clean that up first. Oh, and you don't need to add <html>, <head> or <body> tags in a codepen (those are injected for you). -
Is this any better? http://codepen.io/anon/pen/wWwyPe?editors=011 There was an enhancement made to the new Draggable in GSAP 1.18.5 that makes this type of thing easier (note the second parameter of the update() call being true):
-
By the way, GSAP 1.18.5 was just released and it offers better support for things like this. import { TweenLite, TweenMax, TimelineMax, Elastic } from "gsap"; I got it to work okay in Webpack, Browserify, and RequireJS.
-
For the record, GSAP 1.18.5 has some improvements for compatibility with Webpack/NPM/Browserify/Node. It was released today. You might want to give that a try.
-
@RedGlove, your logo looks like the long-lost brother of our GreenSock logo. Wonder-twin powers, activate! Thanks for pitching in. Oh, and warning: be very careful about using window.onresize because by its very nature, you can only have one callback there, thus if another library (or your own code) had already assigned one, and then you re-assign it, that could mess things up (the other code wouldn't fire). To be safe, you'd have to do something like: var oldOnResize = window.onresize; window.onresize = function(e) { yourNewFunction(e); if (oldOnResize) { oldOnResize(e); } }
-
I didn't notice any major slowdowns but I'm on a fast system. What kind of device are you testing on? It looks like the actual DOM structure is different between those two examples, and I'm curious why you have autoScroll enabled. Perhaps that's part of the problem. Your "smooth" example doesn't seem to offer that same behavior. You also have some arrow <div> elements overlaid on the GSAP one but not the other. And you have overflow:hidden on the body of the "smooth" one, but not the GSAP one. Hiding the overflow could really help the browser avoid doing a bunch of unnecessary rendering work. There are other differences too. Unfortunately I don't have time to pull everything apart and do a detailed analysis for you, but hopefully this gets you moving in the right direction. I'd strongly recommend that when you're doing the comparisons, you make sure that everything is identical as much as possible. And again, reproducing it in codepen will significantly increase your odds of getting a good answer from people in these forums.
-
Like Carl and Jonathan said, it'd be super helpful to see a codepen that we can tinker with, but from glancing at your live page I noticed: You have some JS errors. "frise.html:274 Uncaught TypeError: mySwiper.resizeFix is not a function" You are calling show() or hide() on EVERY drag event (like 60 times per second). That's a jQuery function that probably isn't cheap performance-wise. I'd strongly recommend adjusting the logic you're running to only call show() or hide() when necessary. Like use a variable to track state.
-
What exactly do you need the LEDs to do? It wouldn't be difficult to create a bunch of elements that are arranged like that, but it's important to understand exactly how your client wants the LEDs to animate. Got any examples? Brief description at least?
-
It would be SUPER helpful to see a reduced test case codepen or jsfiddle. It's just so hard to troubleshoot blind. One mistake I've seen people make before when they complain about something like this is that they have a CSS transition applied to the property they're trying to tween, thus every time GSAP sets it (60 times per second), the CSS transition re-starts its transition and there's a funky delay which isn't a problem with GSAP at all. So make sure you don't have any CSS transitions or animations on that element that'd fight with GSAP. Other than that, I don't think we can be of much assistance without some kind of example that lets us see the problem in context.
-
Funny, guys. I'm just a dork who geeks out over code. Anyway, yeah, we've got several plugins that allow you to set merely a velocity and/or acceleration and it'll handle the rest. Physics2DPlugin and PhysicsPropsPlugin specifically. And ThrowPropsPlugin adds another dimension, letting you optionally define an end position (or range or array of specific values and it'll pick the closest natural one) and then it'll glide to a stop. Super useful in some cases. And this stuff doesn't only work for x/y positional values (well, except for Physics2DPlugin which kinda makes sense). You can use it for pretty much any property. Rotation, width, yourCustomProperty, whatever. Once you get the hang of it, it can create some really fun and advanced effects with minimal code. ThrowPropsPlugin can even track the moment-by-moment velocity of any property so that you can feed in that velocity to your tweens. ThrowPropsPlugin.track(element, "propertyName"), then ThrowPropsPlugin.getVelocity(element, "propertyName") Note: all of the plugins mentioned above are membership benefits of Club GreenSock. http://greensock.com/club/
-
I don't think so, no. That'd be a question for Adobe
-
That's probably more of a question for Adobe. I'm not very familiar with what's supported in the mobile AIR stuff, but it wouldn't surprise me if filters weren't available. Did you make sure you activated the GlowFilterPlugin?
- 3 replies
-
- 1
-
-
- glowfilter
- actionscript
- (and 1 more)
-
Yep, we do that in order to keep the smallest footprint in terms of requirements. You can totally use TweenMax for that stuff if you want. Keep in mind that tweenTo() and tweenFromTo() are just convenience methods that: Pause the timeline Create a linear tween of the timeline's "time" That's it. So you could do it yourself like: var from = tl.getLabelTime("nowhere"); var to = tl.getLabelTime("somewhere"); tl.pause(); TweenMax.fromTo(tl, Math.abs(to - from), {time:from}, {time:to, ease:Linear.easeNone, repeat:-1, yoyo:true}); Does that help?
- 3 replies
-
- 5
-
-
- timelinemax
- tweenmax
- (and 2 more)
-
And entire development works in Safari/Chrome but NOT in FireFox
GreenSock replied to fatSkeeter's topic in GSAP
That sounds like a funky glitch in Firefox related to SVG and the fact that it burps if you try animating a property of an SVG element that's not visibly rendered in the DOM (weird, I know). Have you tried the latest version of GSAP? https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.4/TweenMax.min.js We implemented a workaround a while back. Keep in mind that CloudFlare (who runs the CDN) refuses to support the "/latest/" directory anymore (we begged and pleaded but to no avail). So it's probably forever stuck on 1.18.0. You should always target a specific version from now on. 1.18.4 is the latest at this point, although we plan to push out 1.18.5 within the next week. Oh, and the other option is to just make sure that your SVG elements that you plan to animate are actually in the DOM and rendered visually before you try animating them. -
Here are a few of the reasons that I can recall: I was trying to compare some JS-based things with CSS animations/transitions. The only way to do an FPS meter is with JavaScript. The browsers were not reporting things accurately for non-JS things. For example, if I used a requestAnimationFrame loop to measure how many times the screen actually got repainted, it might report as 12fps even though visually it was blatantly obvious that it was more often than that. This is at least partially due to the fact that JS always runs on the main thread but *sometimes* transforms or opacity animations are spun off to a different thread. I found that Dev Tools wasn't reliably reporting things, particularly for CSS-based animations. See http://greensock.com/css-performance/ It made them *appear* to be much less expensive than they actually were. I was told by extremely well-respected members of the Chrome team that they knew FPS counters were inaccurate and there was no way to solve that (at least at that point). Some animations entailed a hybrid of JS and CSS, like Zepto would use JS to fire off animations by applying CSS transitions (via JS). Thus when the CSS stuff was doing its thing, it actually slowed the main thread way down (again, because even if things are theoretically spun off to another thread, there is a bunch of overhead expense, as shown in my video link above). So you'd see this funky delay between when animations would start (they'd get clumped together) and then during the actual animation it'd appear smoother. Since the FPS counter was in the JS level, it was inaccurate. Some FPS counters used requestAnimationFrame while others used setTimeout or setInterval. Some of the core engines (like jQuery) used setTimeout() for animation ticks/iterations, but if you try to measure things with a requestAnimationFrame meter, it's again inaccurate because it's not synced with those setTimout calls. In other words, if jQuery is set to try to run at 100fps, that means 1 tick every 10 milliseconds whereas requestAnimationFrame is capped at 60fps (1 every 16.7ms). You could have some occasions where jQuery runs 2 updates inbetween requestAnimationFrame ticks (two movements, one screen refresh). You can't really use setTimeout() to drive an FPS counter because those aren't synced with screen refreshes (which are typically what people associate with a "frame"). So basically, in order to have a somewhat accurate FPS meter, you must make sure that **everything** you're measuring is also perfectly in sync with requestAnimationFrame ticks. The browser doesn't always cooperate. Oh, and some older browsers don't even offer requestAnimationFrame support. So it just gets really tricky to build something that you can measure accurately across a bunch of devices. In my opinion, it's very easy to miss the point of FPS meters and get side-tracked by the tech. Ultimately, why do we even care about FPS meters? Typically it's because we want to benchmark things so that we know which one will perform better. For animation, "perform better" almost always means "looks smoother". So I tend to put a lot more emphasis on that. Use your eyes. Push things to their limits and see where they break down, and measure the different techniques at that point rather than getting hyper-focused on FPS numbers. I've seen cases where an animation reports a higher frame rate but looks visibly worse than something with a lower FPS number. I have also seen things that made it seem like CSS was better on Chrome on a fast Mac, but then I tried it on some mobile devices and the JS version blew the doors off the CSS one. So it wasn't as easy as just cracking open Chrome and saying "oh, look, the FPS meter says this way is better...cool, we'll go with that." There are other factors too, like the way animation delays are calculated, avoiding layout thrashing, and synchronization across every part of an engine. I explain some of that here along with some comparisons: http://greensock.com/gsap-1-12-0. Again, if you myopically focus on an FPS counter, you may miss some of these other factors that make a big difference in how things will actually look. I hope that's at least a little bit helpful rather than just being utterly confusing.
-
Glad you've got some solutions to choose from. As for performance, remember not to just test the getRatio() function itself - one of the key optimizations we made in the engine was baking in support for the Power eases right inside the render loop, thus getRatio() doesn't even need to get called for Power functions. Skipping function calls helps. So if you're trying to measure performance, make sure you're doing it in the context of actual tweens. But honestly I doubt you'd ever notice a difference unless you're tweening hundreds (probably thousands) of things simultaneously.
-
I don't think I've ever heard of someone wanting an ease that's stronger than Power4, and you're right - we put a heavy emphasis on optimization which is one of the reasons we didn't offer something like you're explaining, but I also see your point about offering a less optimized (but more flexible) option for the rare cases when someone needs it. That being said, we have some other exciting plans that would make this sort of thing irrelevant You'll have to wait and see about that, though. I can't explain too much yet. In the mean time, you're welcome to main your own easing function that does exactly what you're talking about. You can analyze the code in the other eases like Sine to see how to format things. Basically you need to make sure there's a getRatio() method that takes a progress value between 0 and 1 and spits back the converted eased value. Thanks for offering the suggestion. Feel free to keep telling us about ideas you have for improvement.
-
The "jump" at the end is just the browser honoring your "stroke-miterlimit:10" which is set in your HTML inside a <style> block. That basically tells the browser how far to go with rendering the stroke around pointy edges. Change it to stroke-miterlimit:1000 and you'll probably get the effect you want. Or maybe consider changing the stroke-linejoin to "round" (that would be my preference visually)
-
Another technique you could use is with a label: tl.addLabel("dots", 2) .to(".dot1", 0.3, {x:"+=150"},"dots") .to(".dot2", 0.3, {y:"+=150"},"dots+=0.2") .to(".dot3", 0.3, {rotation:"+=150"},"dots+=0.7") .to(".dot4", 0.3, {alpha:0},"dots+=6.2"); I personally prefer Carl's technique with splitting things up into child timelines just because it makes things so modular and easy to create functions that spit back animations that can be nested however/wherever you want. Some people prefer using labels, though. Totally up to you.