GreenSock
Content Type
Profiles
Forums
Store
Blog
Product
Showcase
FAQ
Downloads
Everything posted by GreenSock
-
For the record, you could apply the rotation in an onUpdate callback and base it on the previous location. Here's a relatively simplistic way: http://codepen.io/anon/pen/VagEvd var logo=document.getElementById("logo"), prevX = 0, prevY = 0, RAD2DEG = 180 / Math.PI; TweenMax.to(logo,4,{physics2D:{velocity:300, angle:-60, gravity:100}, onUpdate:autoRotate}); function autoRotate() { var x = logo._gsTransform.x, y = logo._gsTransform.y, angle = Math.atan2(y - prevY, x - prevX) * RAD2DEG; TweenLite.set(logo, {rotation:angle}); prevX = x; prevY = y; }
-
Sorry, Praney, at this point we're not sure we'll release that tool at all. It's a pretty serious undertaking, especially from a support standpoint, and I'm not sure demand would be super high for it anyway. It's definitely a lifesaver in certain circumstances, but I worry that it's a little too geeky for most. We're focusing our resources on other things that would be more likely to appeal to more of our customers.
-
It sounds like you just forgot to load the ScrollToPlugin file. Make sure that's loaded and you'll be good-to-go. <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.4/plugins/ScrollToPlugin.min.js"></script> Oh, and you nested the ease incorrectly - that should go outside the scrollTo object. TweenLite.to(window, 0.5, {scrollTo:{y:topPos}, ease:Power2.easeInOut});
-
The only time you need that special license is if you're using GreenSock tools inside a site/app/product/game for which you're charging a fee from multiple customers. But if you're merely using it in a site where you happen to sell OTHER products (that don't directly use GreenSock in themselves), that qualifies under the standard "no charge" license. For example, if Nike uses GSAP in their site where they sell shoes (but anyone can use the site itself and it's not a membership-only site or something), that's totally fine - no special license is required. Does that answer your question? Even if you do need the license for your particular project (and I bet you don't), typically our customers tell us that the license pays for itself VERY quickly when you consider the time it'll save you, increased capabilities and performance, etc. If it doesn't or you're unhappy for any reason, we'll gladly refund your money - we are passionate about having happy customers around here (as you can hopefully tell by poking around these forums). Happy tweening!
-
Do TimelineMax Constructor Properties Behave as Fallbacks?
GreenSock replied to roblevintennis's topic in GSAP
Thanks for the suggestions, Rob. Sounds almost like a cascading way of defining properties. Ha. "Cascading GreenSock" (CGS) instead of CSS.- 10 replies
-
- 4
-
-
- constructor
- timelinemax
- (and 1 more)
-
Sounds unrelated to GSAP, but I'm curious if adding this line of code to the beginning of your project has any effect: CSSPlugin.defaultForce3D = false; Basically that will make GSAP skip the automatic GPU-acceleration on transforms. If there's a GPU issue on your end, this may resolve things (like if Chrome has to use a software renderer instead of hardware). It's slower, but perhaps it'll get rid of the issue. And again, that's not really a GSAP issue anyway - it just has to do with the browser rendering 2D vs. 3D transforms.
-
I didn't notice any problems, but it sounds like just a rendering issue that is unrelated to GSAP. Remember, the more pixels you change on the screen, the harder you push the browser's graphics rendering routines (thus CPU/GPU load). If you're only changing opacity, it should be pretty fast though. I'm curious why you're using an onUpdate to change the scaleX of the progress bar rather than simply tweening that value directly. That'd certainly be more efficient, but I doubt this is the source of your "jerkiness" problems anyway.
-
TimelineLite seems useful almost always (over TweenLite alone)
GreenSock replied to Thomas James Thorstensson's topic in GSAP
Sure, a timeline is just a container for tweens. There isn't really a down side to wrapping your tweens in a timeline other than a very very slight performance degradation only because there's an extra function call during each render (I can't imagine you'd notice any difference unless maybe you're running tens of thousands of tweens simultaneously...but even then you may not notice). Totally up to you. And of course timelines can be slightly more verbose to create initially. Again, minor point. I'd say use whatever "feels" best to you from a stylistic standpoint. -
I'm not sure I'd say "best" in every case, but yes, autoAlpha has the added benefit of toggling visibility when it makes sense. There's a very slight performance hit during the tween due to the fact that it has to control that additional property but it's pretty negligible. From a rendering standpoint, it is definitely cheaper for the browser if visibility is set to hidden.
-
By the way, I did figure out a way to just check for "display:none" in a relatively cheap way and work around the browser bug/annoyance internally, so I think your concern will be addressed in the upcoming release which you can preview (uncompressed) here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js - better?
-
Not a dumb question - alpha is simply an alias for opacity. No difference whatsoever. It was added originally to help consistency with the Flash API (Flash always used "alpha"). There were a lot of GSAP users coming from the Flash world at the time
-
The direction of the path is dictated by the SVG data itself. But if you don't want (or don't know how) to correct that, you could still just tweak your tween so that it's going backwards How's this?: http://codepen.io/anon/pen/MyZeoZ
-
Ah, I see the issue - it has to do with the fact that Draggable aims to stay out of the way of native touch scrolling by default. Since your Draggable is only set to allow horizontal dragging, imagine what would happen if the user tried scrolling the PAGE up and down vertically (pressing on that Draggable element and moving up/down). See the issue? I don't see an easy way to work around that in a totally automatic fashion (a lot of this has to do with discerning user and developer intention which sometimes gets really tricky). The easy fix in this case is to just set allowNativeTouchScrolling:false on your Draggable. Done Better?
-
Absolutely, you're welcome to release an example. We encourage that sort of thing. The only thing we ask is that you make mention of the fact that GSAP is subject to its own license which is located at https://greensock.com/standard-license/, and maybe encourage them to get GSAP from our own repo or web site just so that they have the latest and greatest version. You don't have to talk about pricing or anything like that. Oh, and of course please don't include any of the members-only plugins in your open source repo Good luck with the project!
-
Please help us gauge if it would be worthwhile to get more involved with creating some products / services for banner developers. Perhaps that would be templates, videos, podcast new tools for fancy effects…we're not sure. Our goal is to better understand the needs out there and see if we can address the pain points, perhaps with a partner of ours who has a ton of knowledge in the banner ad space. http://goo.gl/forms/2ZZ3c3vzRt Please take a few minutes and fill it out; be as brutally honest as possible. If you want to chime in with other ideas that aren't mentioned, that's totally fine too (drop them in this thread below or in the survey itself). Thanks!
-
lockAxis is supposed to just be a boolean (true or false) and it's only useful if you've got a Draggable that can move on multiple axis. Try just removing that - does that fix things for you? If not, it'd be super helpful to see a reduced test case in codepen just so we can see exactly what's going on.
-
You could do something like this: function tween(target, duration, vars) { var tl = new TimelineLite({delay:vars.delay || 0}), copy = {}, p; for (p in vars) { if (p === "position" || p === "scale") { tl.to(target[p], duration, {endArray:vars[p], ease:vars.ease}, 0); } else if (p !== "delay") { copy[p] = vars[p]; } } return tl.to(target, duration, copy, 0); } That way, you can just call tween() kinda like a regular TweenLite.to(), and it'll spit back a TimelineLite that acts exactly the way you want, and is totally controllable. Just a thought.
- 24 replies
-
- 1
-
-
- javascript
- array
- (and 1 more)
-
Thanks for the detailed info (as usual), Blake. You said that we probably don't need that "TweenLite" dependency in there, but wouldn't that cause problems if I removed it because then people couldn't just "require" something like CSSPlugin (or whatever)? It'd break because TweenLite wouldn't be there. I'm curious why that dependency is causing any problems at all, except for SplitText which doesn't really require it anyway. Is it because it assumes a particular directory structure? Are you saying you think it's wisest to just remove the dependencies altogether?
-
@Type1J, I don't quite understand the distinction you're making or why it would matter. Can you help me understand? Either way, you're tweening the exact same array, right? What does it matter if you're pointing at it from an object as well?
-
Nope, that's not a bug - zero-duration tweens render immediately by default. That's what most people find the most intuitive, otherwise if you set() something and then had a line of code right after that which depended on that set() having been applied, it wouldn't work. See what I mean? All you need to do is set immediateRender:false -OR- you can do a set() directly on the timeline instance because in that case, it can tell if you're scheduling it for later. the problem with your example was that you were creating an independent tween (outside the timeline) and when that's created, there's no way for it to know that you're planning to add that to a timeline in the future, and schedule it further out. The timeline set() convenience method has the benefit of knowing that, thus it'll set immediateRender:false for you (unless it's at the very beginning of the timeline). Make more sense now?
- 1 reply
-
- 4
-
-
And by the way, you can type this into the console to find out on any live page: TweenLite.version
-
Excellent. Glad it's all working now (right?) Thanks for reporting back.
-
Yep, that was already fixed in 1.18.4
-
I really appreciate the thoughtful response and detailed advice. We rarely get complaints about folks not being able to get the paid-for stuff via NPM or Github - they're typically very understanding of how dicey that'd be and are happy to snag things via the zip download but we'll certainly keep this in mind if we get a lot of requests and/or if it becomes more feasible with future tech. We just don't have the resources at this point to throw at an endeavor like this. Thanks again.
-
Oh, that's correct - x/y transforms are always px-based. That's in the documentation. It's mostly due to the nature of transforms and matrices that undergird them.