Jump to content

GreenSock last won the day on July 24 2019

GreenSock had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


Blog Post Comments posted by GreenSock

  1. @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.
  2. @zync, you control the amount of stagger using the stagger parameter. You cannot alter that with a dynamic function if that's what you meant. And these changes are for HTML5/JS only. Demand for the Flash version is tiny now that browsers are phasing Flash out, so all of our attention is on the HTML5/JS toolset at this point.
  3. Many of the networks seem to want to keep their CDN links "confidential" at this point to ensure that other sites/ads don't "steal" their resources. As for DoubleClick specifically, I know they're working out a few things internally about where exactly GSAP will "officially" be hosted but I expect they'll have that squared away within the next few weeks. We were given a URL but were asked not to share it publicly quite yet. Basically, it's best to contact each network for their CDN URLs.
  4. We have spoken directly with the companies you mentioned. All were given advanced access to this article in fact. But I don't blame you for being perplexed, as some of the networks are having a tough time communicating answers not only to customers, but even internal staff (at least it seems that way from the outside because of the mixed messages we hear about out there). And yes, ultimately some publishers can refuse to exempt certain files from the calculation but from what we understand that's pretty rare (for GSAP at least). The IAB will be releasing a document soon that will likely have a short list of libraries that are recommended for exemption. We're pretty confident GSAP is on that list ;) Hopefully that'll help publishers get on board.
  5. @noco, I totally see why TweenNano is appealing in your situation, but as I tried to explain in the article, creating it could actually cause a lot of problems. Within a matter of weeks (or maybe months), it should be a non-issue. If we cave and create it because of the short-term pressure, it could have long-term consequences and ultimately be bad for the industry. I know, it sounds weird. But we're trying to take a longer-term view. If publishers or networks are forcing you to fit HTML5 ads into 40kb, I'd strongly recommend that you have them read this article.
  6. @flysi3000: gzipping is a server-side thing, yes. You don't actually zip your files manually or anything. As for the browser-targeting matrix, could you provide more details? What were you envisioning specifically? Like something that showed what CSS properties are available/tweenable in each major browser? If so, caniuse.com is excellent.
  7. @EarMaster, I'm not sure where you got that 400kb figure (we suggested half that), but I agree that it'd be unwise to raise the limit so much that bloated banners clog up our connections. It's always a balancing act. With HTML5, it simply isn't realistic to get rich, creative banners down to 100kb including all the assets. Bandwidth is constantly rising and the 40kb limit was last updated back in 2003. Even if we only look at the numbers since 2008 (and that's being VERY generous), the bandwidth has risen by over 5.5x. Thus the 200k limit is actually far less proportionally than the original 40kb limit. When you look at the ratios, 200kb is quite conservative. Perhaps you can crank out creative animated banners in 100-120kb, but I think for the average designer/developer out there, it's VERY difficult to do in HTML5.
  8. @hhdev, our recommendation at this point is to help educate those who are still dragging their feet and imposing the archaic 40kb limit. Send them a link to this article and/or have them talk with the major networks to see that these strategies are being adopted widely. From our research, almost all of the big players are on board and modernizing specs even without IAB input. Leveraging the ubiquity and performance of GSAP will not only make those networks/publishers more appealing to advertisers, but ultimately it will allow them to improve loading times and runtime performance. We'd definitely encourage folks to favor networks that have realistic HTML5 specs and allow tools like GSAP without counting the file size against the ads. The publishers that persist in dragging their feet will have less and less business, putting pressure on them to modernize (at least in theory). The market needs to send a message.
  9. @daweed31, we may add smoothOrigin for "normal" DOM elements at some point, but we wanted to gauge the interest level of our user base first and see how well-received the SVG-specific feature was. If others want smoothOrigin for normal DOM elements, please let us know. The more requests we get, the more likely we'll add it but there are some complexities we'll have to overcome if we go down that path.
  10. Yeah, I think that's pretty fair, Karsten. If you're only going to be doing very simple stuff and don't need much backward compatibility, CSS is great. Very easy to sprinkle in rollovers or basic state changes. The challenge is that sometimes you *think* you'll only need simple stuff at the outset of your project, and then things change and it can get awkward if you choose a technology that has such limitations. "Oh shoot...we need an elastic ease? We need to rotate that thing while it's moving, but offset the start times? Umm..." You could always switch later, and maybe just use JS for the parts where you need more advanced features and cross your fingers that there won't be overlaps or integration needed between the two at some point. If you build with CSS, it could be a problem. If you build with JS, it won't. It's like buying an 8GB iPhone (or whatever) instead of one with more memory. Perhaps today you only have 7GB worth of needs, but when you get more music and apps, you might kick yourself for limiting your options. Example: you build an sequenced animation but then later add a login overlay that should pause all the animation on the page (or gradually slow them to a halt) and then resume when the user closes the window. Hm. If it's all built in CSS, it could get VERY code-heavy or impossible whereas if it's built with GSAP, it's maybe 2 lines of code. Done. If you don't want/need that kind of flexibility, CSS may be a great fit. Your point is completely valid - in most real-world projects, the performance difference between GSAP and CSS animations probably won't be the deciding factor anymore. I think that's great news. A few more thoughts can be found in this article from a while back: http://greensock.com/transitions/
  11. What a thoughtful response, Paul! Thanks for all the clarifications. Let me offer a few as well: FPS counter The goal had nothing to do with accurately measuring how often pixels got repainted (I tried explaining that in the video, but probably did a poor job and I guess naming it "FPS" added to the confusion). The sole purpose of that fps ticker was to measure the main thread performance, since JS only runs there. I wanted to show that there can be a cost on the main thread even when CSS animations of only transforms are running (which are widely assumed to run on a different thread, thus we'd expect the main thread to perform better, not worse). If I could do the video over, I'd explain this better. Sorry about that. Animating elem.style.top Very true - thanks for bringing it up. Keep in mind that the goal was to show that animating anything other than transforms/opacity along with those can have sync problems. It could be backgroundColor, padding, whatever. "top" was just easiest to see in the tests, that's all. I agree though - in 98% of the cases, it's best/fastest to animate position using transforms (I have seen cases where top/left is much more performant, but that's a rabbit trail). This is an unfair benchmark You said it's doable to independently control the transform components (x/y/scale/rotation) on a single element with CSS animations (including varying the start/end times and easing) - I'm very curious to see this. Your example codepen doesn't do that. Instead, it does all of them at the same time. Can you provide one that separates them properly? This is super important, and it's actually what prompted me to do this whole test originally - a guy emailed me saying that CSS animations could do what GSAP does in terms of independent control, but it requires nesting and my point was that the nesting probably wasn't "free" - there's a performance cost. Notice that x/y animate for the whole 10 seconds, but rotation only occurs during a middle portion (for 6 seconds) and the scale changes toward the end (for 4 seconds). As far as I know, this is simply impossible with CSS animations (without nesting). Did I misunderstand? Thanks again for chiming in, Paul. I've got massive respect for you personally and the whole crew over there at Google. You guys are doing wonderful things for moving the web forward, especially on the performance front.
  12. Farzan, what would widthPercent/heightPercent map to? Wouldn't the effect be the same as xPercent/yPercent? Is there some other CSS property that it would correlate with?
  13. Sorry to "hear" about the audio problems (sorry, couldn’t resist). Frankly, I haven't dealt much with audio in HTML5 yet, but my understanding is that it's a huge pain right now. I'm sure it’ll get better eventually. We may tackle something like that in the future, but right now we’re staying laser-focused on animation. You should be able to synchronize audio with a TimelineLite/Max by simply using a setInterval() (or something like that) to poll the audio's time and adjust the timeline’s time(). I hope that helps (at least a little). Happy tweening!
  14. Daniel, I think you're right about simple transitions of states - those are quite simple to do directly in CSS (as long as you don't require compatibility with IE9 or earlier). However, if you're doing anything more advanced, I'd argue that CSS is not at all "more lean" and in fact it becomes quite cumbersome. See the article and videos Carl did here: http://www.greensock.com/css-workflow/. Also read about many of the limitations of CSS animation and some myths that a lot of people believe at http://css-tricks.com/myth-busting-css-animations-vs-javascript/ Thanks for chiming in!
  15. I can't imagine how that could possibly be a GSAP "bug" because at its core, all GSAP does is set css properties over time. No voodoo magic. It isn't like if you set those through some other means (your own JS), the problem would disappear (please correct me if I'm wrong in this case). Those rendering issues certainly sound like browser bugs. I haven't seen anything like that, nor has anyone else reported something similar.
  16. No, we didn't specifically hardware-accelerate GSAP in the demo speed test. We certainly could have set force3D:true, but the goal was to be very fair and do an apples-to-apples comparison (as much as possible at least). Doing translate3d() can actually negatively impact performance in certain situations, like when you're doing a TON of elements/layers. And if I remember correctly, backface-visibility can hurt performance as well (again, it's not a blanket rule). Thanks for asking.
  17. You're absolutely right that ultimately things boil down to running code at an interval that updates style properties. The key, however, is doing that as efficiently as possible within an architecture that delivers a lot of flexibility (sequencing, altering timeScale, reversing on-the-fly, accommodating many different easing effects, plugins, etc.) As far as how GSAP is able to be so fast, there's no simple answer because it's a combination of a BUNCH of techniques. From using linked lists to inlining logic to using bitwise operators to baking in most of the common easing calculations in the main rendering loop to minimizing the calling of functions and structuring things to make it easier for modern JITs to discern data types and optimize compilation as well as creating a super-fast algorithm for finding conflicting tweens and releasing objects for garbage collection, etc. It's definitely not a simplistic thing :) I think jQuery just wasn't built with highly optimized animation in mind, that's all. I can't fault the authors - they've done an amazing job at what jQuery was supposed to be. GSAP, however, is built specifically for high-performance, professional-grade animation. There are a lot of architectural decisions made accordingly. You're also right about the fact that this site would naturally feature battles where GSAP does well, but we've tried very hard to be fair and very honest. You're welcome to run your own tests and if they contradict our results, we'll surely *not* post them ;)
  18. Yes, hardware acceleration and battery savings are definitely key considerations. And I think there's a misperception out there that CSS transitions/animations deliver hardware acceleration (and battery savings) but JS-based animation doesn't. In reality, though, there's all sorts of things that can be done in JS that offload compositing to the GPU and limit animation calculations to only when the screen is refreshing and throttling back significantly when the user switches to another tab, for example (to conserve battery). GSAP already does that. For example, using requestAnimationFrame by default. And there's a force3D flag you can set to make transforms use the GPU-accelerated flavor. And have you seen CSS transitions performance in iOS 7? I just posted a side-by-side comparison here: http://www.greensock.com/ios7/. It's shockingly bad. I was expecting hardware acceleration to get better and better, but no dice in iOS 7. Very strange. Anyway, thanks for chiming in and bringing up the very valid considerations folks should keep in mind.
  19. Thanks for mentioning that, Richard. Actually, IE10's "simulation" IE8 is very inaccurate. If you view the page using "real" IE8, you'll see that things animate nicely including scale and rotation. Of course the 3D flipping is ignored since IE8 doesn't support 3D.
  20. Sorry to hear about the trouble, Ram. I just checked in Chrome 29 and it worked flawlessly. No crash at all in Windows or Mac. Nobody else has reported issues like that either. I wonder if it's an issue specific to your system, unrelated to GSAP. Perhaps it's a video card driver issue? The good news is that GSAP appears to work great in Chrome 29 (at least from what I can tell).
  21. Yep, unfortunately IE10 doesn't support "preserve-3d" transform style. That's completely unrelated to GSAP, though - it's just a css thing that the browser doesn't support. There's no way (that I know of) to get around that. Kinda like trying to do 3D transforms in IE6 or something - it ain't gonna happen because of the limitations of the browser itself. To be clear, 3D does work in IE10, just not the preserve-3d css which makes it easy to put 3D elements into a container and then move the container while keeping all the z-depth stuff intact that's inside.
  22. Torak, CSSPlugin already supports clip, but I assume you're talking about non-rectangular shapes/masks and that will likely be supported when the browser vendors fall in line and support it consistently. We're not generally interested in adding experimental stuff to CSSPlugin because if the spec changes or browsers implement things differently, it could cause a lot of problems. In the mean time, you could certainly create your own plugin for this type of functionality. If you need help, hit us up in the forums at http://forums.greensock.com