Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'workflow'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge


  • FAQ Landing Page


  • Examples
  • Showcase


  • Products
  • Plugins


  • Learning Center
  • Blog


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website



Company Website



Found 9 results

  1. As the author of GSAP I'm sometimes asked if the Web Animations API (WAAPI) will be used under the hood eventually. My responses have gotten pretty long so I thought I'd share my findings with everyone here. Hopefully this sheds light on the challenges we face and perhaps it can lead to some changes to WAAPI in the future. WAAPI is a native browser technology that's similar to CSS animations, but for JavaScript. It's much more flexible than CSS animations and it taps into the same mechanisms under the hood so that the browser can maximize performance. Overall support is has gotten pretty good but there are multiple levels to the spec, so some browsers may support only "level 1", for example. The hope is that eventually all major browsers will support WAAPI fully. Progress in that direction has been very, very slow. You could think of WAAPI almost like a browser-level GSAP with a bunch of features stripped out. This has led some to suggest that perhaps GSAP should be built on TOP of WAAPI to reduce file size and maximize performance. Ideally, people could tap into the rich GSAP API with all of its extra features while benefiting from the browser's native underpinnings wherever possible. Sounds great, right? Unfortunately, WAAPI has some critical weak spots that make it virtually impossible for GSAP to leverage it under the hood (at least in any practical manner). I don't mean that as a criticism of WAAPI. In fact, I really wanted to find a way to leverage it inside GSAP, but I'll list a few of the top reasons why it doesn't seem feasible below. To be clear, this is NOT a feature comparison or a bunch of reasons why GSAP is "better" - these are things that make it architecturally impossible (or very cumbersome) to build GSAP on WAAPI. Custom easing WAAPI only supports cubic-bezier() for custom easing, meaning it's limited to one segment with two control points. It can't support eases like Bounce, Elastic, Rough, SlowMo, wiggle, ExpoScaleEase, etc. GSAP must support all of those eases plus any ease imaginable (unlimited segments and control points - see the CustomEase page). This alone is a deal-breaker. Expressive animation hinges on rich easing options. Independent transform components The most commonly animated values are translation (x/y position), rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving (translate) something and then halfway through start rotating it and stagger a scale toward the end: |-------- translateX() ------------| |------ rotate() ------| |---------- translateY() -----------| |-------------- scale(x,y) --------------| Animators NEED to be able to independently control these values in their animations. Additive animations (composite:"add") probably aren't an adequate solution either. It's unrealistic to expect developers to track all the values manually or assume that stacking them on top of each other will deliver expected results - they should be able to just affect the rotation (or whatever) at any time, even if there was a translate() or scale() applied previously. GSAP could track everything for them, of course, but continuously stacking transforms on top of each other seems very inefficient and I imagine it'd hurt performance (every transform is another matrix concatenation under the hood). There is a new spec being proposed for translate, scale, and rotate CSS properties which would certainly help, but it's not a full solution because you still can't control the x/y components independently, or all of the 3D values like rotationX, rotationY, z, etc. This is an essential feature of GSAP that helped it become so popular. Example See the Pen Independent Transforms Demo by GreenSock (@GreenSock) on CodePen. Custom logic on each tick Certain types of animations require custom logic on each tick (like physics or custom rounding/snapping or morphing). Most GSAP plugins rely on this sort of thing (ModifiersPlugin, for example). I'm pretty sure that's impossible with WAAPI, especially with transforms being spun off to a different thread (any dependencies on JS-based logic would bind it to the main thread). Non-DOM targets As far as I know, WAAPI doesn't let you animate arbitrary properties of generic objects, like {myProperty:0}. This is another fundamental feature of GSAP - people can use it to animate any sort of objects including canvas library objects, generic objects, WebGL values, whatever. Global timing controls I don't think WAAPI lets you set a custom frame rate. Also, GSAP's lag smoothing feature requires the ability to tweak the global time (not timeScale - I mean literally the current time so that all the animations are pushed forward or backward). As far as I know, it's impossible with WAAPI. Synchronization (transforms and non-transforms) As demonstrated in this video, one of the hidden pitfalls of spinning transforms off to another thread is that they can lose synchronization with other main-thread-based animations. As far as I know, that hasn't been solved in all browsers. We can't afford to have things getting out-of-sync. Some have proposed that GSAP could just fall back to using a regular requestAnimationFrame loop to handle things that aren't adequately supported by WAAPI but that puts things at risk of falling out of sync. For example, if transforms are running on a separate thread they might keep moving while other parts of the animation (custom properties that get applied somehow in an onUpdate) slow down or jank. Compatibility GSAP has earned a reputation for "just working" across every browser. In order to deliver on that, we'd have to put extra conditional logic throughout GSAP, providing fallbacks when WAAPI isn't available or doesn't support a feature. That would balloon the file size substantially and slow things down. That's a tough pill to swallow. WAAPI still isn't implemented in several major browsers today. And then there are the browser inconsistencies (like the infamous SVG origin quirks) that will likely pop up over time and then we'd have to unplug those parts from WAAPI and maintain the legacy raw-JS mechanisms internally. Historically, there are plenty of cross-browser bugs in natively-implemented technologies, making it feel risky to build on top of. Performance WAAPI has a performance advantage because it can leverage a separate thread whereas JavaScript always runs on the main thread, right? Well, sort of. The only time a separate thread can be used is if transforms and/or opacity are the only things animating on a particular element (or else you run into synchronization issues). Plus there's overhead involved in managing that thread which can also get bogged down. There are tradeoffs either way. Having access to a different thread is fantastic even if it only applies in certain situations. That's probably the biggest reason I wanted to leverage WAAPI originally, but the limitations and tradeoffs are pretty significant, at least as it pertains to our goals with GSAP. Surprisingly, according to my tests GSAP was often faster than WAAPI. For example, in this speed test WAAPI didn't perform as well as GSAP on most devices I tried. Maybe performance will improve over time, but for now be sure to test to ensure that WAAPI is performing well for your animations. File Size To ensure compatibility, GSAP would need all of its current (non-WAAPI) code in place for fallbacks (most browsers won't fully support WAAPI for years) and then we'd need to layer in all the WAAPI-specific code on top of that like conditional logic checking for compatible eases, sensing when the user is attempting something WAAPI can't support, tracking/stacking additive animations, etc. That means file size would actually be far worse if GSAP were built on WAAPI. Some have suggested creating a different adapter/renderer for each tech, like a WebAnimationsAdapter. That way, we could segregate the logic and folks could just load it if they needed it which is clever but it doesn't really solve the problem. For example, some plugins may affect particular CSS properties or attributes, and at some point conditional logic would have to run to say "oh, if they're using the WebAnimationsAdapter, this part won't work so handle it differently". That conditional logic generally makes the most sense to have in the plugin itself (otherwise the adapter file would fill up with extra logic for every possible plugin, bloating file size unnecessarily and separating plugin logic from the plugin itself). So then if anyone uses that plugin, they'd pay a price for that extra logic that's along for the ride. Weighing the Pros & Cons At the end of the day, the list of "pros" must outweigh the "cons" for this to work, and currently that list is quite lopsided. I'd love to find a way to leverage any of the strengths of WAAPI inside GSAP for sure, but it just doesn't seem feasible or beneficial overall. The main benefit I see in using WAAPI inside GSAP is to get the off-the-main-thread-transforms juice but even that only seems useful in relatively uncommon scenarios, and it comes at a very high price. I'm struggling to find another compelling reason to build on WAAPI; GSAP already does everything WAAPI does plus a lot more. I'm hopeful that some of the WAAPI benefits will someday be possible directly in JS so that GSAP wouldn't have to create a dependency on WAAPI to get those. For example, browsers could expose an API that'd let developers tap into that off-the-main-thread transform performance. Ideally, browsers would also fix that hacky matrix()/matrix3d() string-based API and provide a way to set the numeric matrix values directly - that'd probably deliver a nice speed boost. Please chime in if I'm missing something, though. (Contact us or post in the forums) Why use GSAP even if/when WAAPI gets full browser support? Browser bugs/inconsistencies Lots of extra features like morphing, physics, Bezier tweening, text tweening, etc. Infinite easing options (Bounce, Elastic, Rough, SlowMo, ExpoScaleEase, Wiggle, Custom) Independent transform components (position, scale, rotation, etc.) Animate literally any property of any object (not just DOM) Timeline nesting (workflow) GSDevTools Relative values and overwrite management from() tweens are much easier - you don't need to get the current values yourself Familiar API Why WAAPI might be worth a try If you don’t need broad browser support today or any of GSAP’s unique features, you could save some kb by using WAAPI Solid performance, especially for transforms and opacity Always free Again, the goal of this article is NOT to criticize WAAPI at all. I think it's a great step forward for browsers. I just wanted to explain some of the challenges that prevent us from using it under the hood in GSAP, at least as it stands today. EDIT: Brian Birtles, one of the primary authors of the WAAPI spec, reached out and offered to work through the issues and try to find solutions (some of which may involve editing the spec itself) which is great. Rachel Nabors has also worked to connect people and find solutions. Although it may take years before it's realistic to consider building on WAAPI, it's reassuring to have so much support from leaders in the industry who are working hard to move animation forward on the web. 2020 EDIT: Now Brian Birtles is the only one working on WAAPI and he does so on a volunteer basis, so further development of WAAPI has understandably slowed down in recent times.
  2. https://css-tricks.com/tips-for-writing-animation-code-efficiently/
  3. GreenSock

    Ease Visualizer

    The ease-y way to find the perfect ease A solid mastery of easing is what separates the top-notch animators from the hacks. Use this tool to play around and understand how various eases "feel". Notice that you can click the underlined words in the code sample at the bottom to make changes. Some eases have special configuration options that open up a world of possibilities. If you need more specifics, head over to the docs. Quick Video Tour of the Ease Visualizer A special thanks to Jamie Barlow who built almost the entire thing. He's one of our all-stars in the forums, lending his wisdom and animation prowess to our whole community. He's a rock star. Take your animations to the next level with CustomEase CustomEase frees you from the limitations of canned easing options; create literally any easing curve imaginable by simply drawing it in the Ease Visualizer or by copying/pasting an SVG path. Zero limitations. Use as many control points as you want. Grab CustomEase below or find out more.
  4. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. If you've ever coded an animation that's longer than 10 seconds with dozens or even hundreds of choreographed elements, you know how challenging it can be to avoid the dreaded "wall of code". Worse yet, editing an animation that was built by someone else (or even yourself 2 months ago) can be nightmarish. Our article on CSS-Tricks, Writing Smarter Animation Code, will show you how to keep your code manageable and speed up your workflow. Here's just a taste of what's covered: Benefits of timelines Nesting timelines Creating functions that return timelines Using GSDevTools to super-charge your workflow This article contains what we consider to be two of our most important videos. Definitely watch them both. We're confident these tips will truly revolutionize how you approach your complex animations. Read Writing Smarter Animation Code.
  5. GreenSock

    Animating SVG with GSAP

    When it comes to animation, SVG and GSAP go together like peanut butter and jelly. Chocolate and strawberries. Bacon and...anything. SVG offers the sweet taste of tiny file size plus excellent browser support and the ability to scale graphics infinitely without degradation. They're perfect for building a rich, responsive UI (which includes animation, of course). However, just because every major browser offers excellent support for displaying SVG graphics doesn't mean that animating them is easy or consistent. Each browser has its own quirks and implementations of the SVG spec, causing quite a few challenges for animators. For example, some browsers don't support CSS animations on SVG elements. Some don't recognize CSS transforms (rotation, scale, etc.), and implementation of transform-origin is a mess. Don't worry; GSAP smooths out the rough spots and harmonizes behavior across browsers for you. There are quite a few unique features that GSAP offers specifically for SVG animators. Below is a list of common challenges along with GSAP solutions. This page is intended to be a go-to resource for anyone animating SVG with GSAP. Challenge: Scale, rotate, skew, and move using 2D transforms No problem. 2D transforms work exactly like they do on any other DOM element. gsap.to("#gear", {duration: 1, x: 100, y: 100, scale: 0.5, rotation: 180, skewX: 45}); IE and Opera don't honor CSS transforms at all, so GSAP applies these values via the SVG transform attribute like: <g id="gear" transform="matrix(0.5, 0, 0, 0.5, 100, 0)">...</g> When it comes to animating or even setting 2D transforms in IE, CSS simply is not an option. #gear { /* won't work in IE */ transform: translateX(100px) scale(0.5); } Very few JavaScript libraries take this into account, but GSAP handles this for you behind the scenes so you can get amazing results in IE with no extra hassles. Challenge: Set the transformOrigin (the point around which rotation and scaling occur) Another unique GSAP feature: use the same syntax you would with normal DOM elements and get the same behavior. For example, to rotate an SVG <rect> that is 100px tall by 100px wide around its center you can do any of the following: gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50% 50%"}); //percents gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "center center"}); //keywords gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50px 50px"}); //pixels The demo below shows complete parity between DOM and SVG when setting transformOrigin to various values. We encourage you to test it in all major browsers and devices. More Details Morph <path> data even if the number (and type) of points is completely different between the start and end shapes! Most other SVG shape morphing tools require that the number of points matches. Morph a <polyline> or <polygon> to a different set of points There's a utility function, MorphSVGPlugin.convertToPath() that can convert primitive shapes like <circle>, <rect>, <ellipse>, <polygon>, <polyline>, and <line> directly into the equivalent <path> that looks identical to the original and is swapped right into the DOM. Optionally define a "shapeIndex" that controls how the points get mapped. This affects what the in-between state looks like during animation. Instead of passing in raw path data as text, you can simply feed in selector text or an element and the plugin will grab the data it needs from there, making workflow easier. MorphSVGPlugin is a bonus plugin for Club GreenSock members (Shockingly Green and Business Green). Other SVG Gotchas GSAP does a lot to remove the hurdles of animating with SVG, but there are still a few things to keep in mind: The current SVG spec does not account for 3D transforms. Browser support is varied. Best to test thoroughly and have fallbacks in place. There are quite a few browser bugs related to CSS transforms on SVG elements, some of which can interfere with GSAP's ability to animate things properly so we'd strongly recommend only using GSAP to apply transform-related properties like scale, rotation, x, y, etc. In Chrome (at least as of June 2015), getComputedStyle() returns the WRONG transform values on SVG elements. It doesn't recognize any non-identity values. So, for example, if you apply a class to an SVG element and it has transform: scale(0), Chrome will say its computed scale is 1. Doh! The same goes for any transforms - if you rotate or move or whatever in CSS, Chrome reports it as scale:1, rotation:0, translate:0, etc. So when GSAP asks the browser for the current value, it'll get bogus data. In Firefox, if you apply a CSS transform to an SVG element, it overrides any transform that is applied via the transform attribute. So if you inspect the element in Dev Tools, you'll see that GSAP is animating the values perfectly in the SVG's transform attribute, but visually you'll see no changes because the CSS class defines something like transform: scale(0) which takes precedence over the transform attribute. As far as we know, there's no way for GSAP to work around this, so it's best to just avoid defining transforms via CSS and use GSAP directly, like gsap.set(..., {scale: 2, rotation: 30, ...}) Most browsers don't GPU-accelerate SVG elements. GSAP can't change that. SVG is lightweight and resolution-independent, but that also can be costly when it comes to performance because rather than just shoving rasterized pixels around (which GPUs are really good at), browsers have to calculate the geometry/paths on each frame. Flash developers will remember converting vectors to bitmaps using cacheAsBitmap. In Flash Player this led to considerable performance gains. Will be interesting to see if browsers offer developers a similar option. Browser support All SVG features in this article will work in IE9+ and all other major desktop and mobile browsers unless otherwise noted. If you find any cross-browser inconsistencies please don't hesitate to let us know in our support forums. Inspiration The SVG Animations collection above is just a small sampling of Chris' work. Be sure to also check out Chris Gannon's full portfolio on CodePen and follow him on Twitter for a steady influx of inspiration. Awesome SVG Resources SVG Gotchas! Understanding SVG Coordinate Systems and Transformations - Sara Soueidan Improving SVG Runtime Performance - Taylor Hunt A Compendium of SVG Information - Chris Coyier Weighing SVG Animation Techniques (with Benchmarks) - Sarah Drasner Making SVGs Responsive with CSS - Sara Soueidan How to Scale SVG - Amelia Bellamy-Royds Transforms on SVG Elements - Ana Tudor Get Started Quickly with GSAP Below are a few resources that will get you up and running in no time: Getting Started Guide with Video Sequence Animations like a Pro (video) GSAP Documentation
  6. Feature lists are nice, but they can get lengthy and they don't always tell the story in a way that's relevant to you as the developer or designer in the trenches, trying to get real work done for real clients. You hear plenty about theoretical benefits of CSS animations or some whiz-bang library that claims to solve various challenges, but then you discover things fall apart in all but the most modern browsers or the API is exceedingly cumbersome or there are frustrating "gotchas". You need things to just work. .expander { cursor: pointer; font-weight: 400; position: relative; } section .card{ padding-bottom: 6px; margin-bottom: 10px; padding-left: 35px; padding-top: 6px; box-shadow: none; } .expandable-list { padding-left: 0; } .expandable-content { padding: 0; height: 0; overflow: hidden; } .expander-button { position: absolute; border-radius: 50%; background-color: #BBB; width: 15px; height: 15px; display: inline-block; vertical-align: middle; border: 1px solid #FFF; margin-top: 8px; /* vertically center with heading top: 50%; margin-top: -9px; */ left: -8px; margin-left: -18px; font-size: 0px; } .expander-plus, .expander-minus { position: absolute; background-color: #FFF; display: block; } .expander-plus { width: 1px; height: 7px; left: 6px; top: 3px; } .expander-minus { width: 7px; height: 1px; top: 6px; left: 3px; } .project-post p { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .project-post h2 { padding-top: 16px; margin-bottom: 10px; } .expPoint, .project-post .expList li { font-size: 1.1em; list-style: none; line-height: normal; margin: 0px 0px 0px 8px; padding: 6px 4px 4px 20px; position:relative; border: 1px solid rgba(204,204,204,0); } .expPoint, .expContent { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .expPoint:hover, .project-post .expList li:hover { background-color:white; border: 1px solid rgb(216,216,216); } .expContent { height: 0px; overflow: hidden; color: #656565; font-size: 0.9em; line-height: 150%; font-weight: normal; margin: 5px 0px 0px 0px; padding-top: 0px; } .toggle { width:6px; height:8px; position:absolute; background-image:url(/_img/toggle_arrow.gif); background-repeat: no-repeat; left: 9px; top: 12px; } .expMore { color: #71b200; text-decoration: underline; font-size:0.8em; } #featureAnimation, #featureBox { background-color:#000; border: 1px solid #333; height: 220px; overflow:hidden; line-height: normal; font-size: 80%; } #featureAnimation { position:relative; visibility:hidden; } #featureBox { position:absolute; } #featureAnimation, #featureBox, #whyGSAP, .featureTextGreen, .featureTextWhite { width: 838px; } #whyGSAP, .featureTextGreen, .featureTextWhite { text-align: center; } #whyGSAP, .featureTextGreen, .featureTextWhite { font-size:50px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; top:0; } .featureTextGreen { color:#91e600; font-weight: bold; } .featureTextWhite { color:white; font-weight:normal; } .star { position: absolute; width: 16px; height: 16px; display: none; } #browserIcons { top:64px; left: 100px; width: 92px; height: 92px; position: absolute; text-align:left; } #browserIcons img { position:absolute; } .featureTextMinor { color:#CCCCCC; font-weight:normal; font-size:20px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; visibility:hidden; } .dot { position:absolute; background-color: #91e600; } #ctrl_slider { position:absolute; width: 725px; height:10px; left:18px; top:196px; background: rgba(80,80,80,0.3); border:1px solid rgba(102,102,102,0.5); visibility:hidden; } Why GSAP? Performance Compatibility Other tools fall down in older browsers, but GSAP is remarkably compatible. Scale, rotate & move independently (impossible with CSS animations/transitions) XNJYHQLJYQEW CSS, canvas libraries, colors, beziers, etc. Total control pause(), play(), reverse(), or timeScale() any tween or sequence. GSAP The new standard for HTML5 animation replay
  7. Back in the Flash days it was easier to get these things right. Now is again the wild west and trying to get estimation and pricing in the right spot is quite an art I think. From my agency experience I usually put 8 hrs per banner and 4 hrs per resize, but you know there all different kind of clients from those who sent you the final PSD to to those that take you through 10 rounds of review with 3 re-designs during the project with an non-changing deadline. Right now whenever I plan a banner the first thing I do is see if I can do it all in HTML/DOM with GSAP/JS/CSS3 which is a cheaper workflow (Photoshop and Sublime only) than say Easel JS (which requires separation of Design and Developer tasks and some Flash experience). Do I need to use and animate SVG? Increase the hours. Do I need to use canvas? Increase the hours. Then I remember that I'm probably estimating like in my Flash days so I multiply the hours by 1.5 since HTML is slower. Do you charge per hour or per banner? Are clients more willing to pay per banner of per developer hour? Is it cheaper now or is more expensive with HTML5? How do you manage large campaigns with say 50 banners? Where do you cut costs to be competitive? Let's talk about the art and science of making banners.
  8. So, can I deliver banner files gzipped? I have an ad that we converted with Swiffy; it looks amazing, and right there, in the Swiffy output window, it shows the file size of the banner as 88k -- but it's the gzipped file size. The raw file size of the html when I download it, is 346k. I'm pretty sure I can use gzipped files in Doubleclick, but what about other media people/publishers? Anyone have experience with this?
  9. Does anyone have a preferred method for making sure that everything that's supposed to be hidden when the banner loads is actually hidden? I've had a recurring issue where sometimes, there's a quick flicker of all the hidden text/graphics before the animation kicks in. Currently, everything's fading in using .from autoAlpha:0, and it usually works, but is there something that's more bulletproof? Thanks!