Jump to content
GreenSock

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

Search the Community

Showing results for tags 'performance'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

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

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

Categories

  • FAQ Landing Page

Categories

  • Examples
  • Showcase

Categories

  • Products
  • Plugins

Categories

  • Learning Center
  • Blog

Categories

  • ScrollTrigger Demos

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Twitter


CodePen


Company Website


Location


Interests

  1. Hi, Is there a special / approved way of measuring animation performance on the client? I would like to measure if the animation has lagged vs specified duration, or if greensock was being clever under the hood and skipped frames to optimise the animation. Currently I'm using a onComplete call within gsap.to to print the end of animation time, and comparing that to a time from just before the animation was called. This way I'd be able to turn off animation effects automatically across the site based on some initial test, for slower performance devices. One extreme edge case was when I opened a web app in a virtualised macOS machine that did not have GPU passthrough, so simple transform animations would freeze the entire machine. Would avoid having these problems by running a small transform animation test for a few ms duration to see how it performed, then decide on the animations for rest of site. EDIT: The timestamping method doesn't work well for performance measurement - testing shows the elapsed ms from before gsap.to() to onComplete call could be less than the duration specified in gsap.to(). EDIT2: For anyone having the same experiment with a virtualised machine for dev environment, the guest OS / Safari doesn't freeze or drop frames as per the fps measuring function given by Jack below. It's likely about how VMware renders the graphical output of the guest OS back to you on the host OS that freezes / drop frames.
  2. Hi there ! I have a horizontal scroll in place with Scrolltrigger. I was wondering if it was possible to disable animating elements when they're out of the viewport for performance matter ? Juste like Locomotive scroll : https://locomotivemtl.github.io/locomotive-scroll/ Thanks for your feedback
  3. 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 standard for HTML5 animation replay
  4. Hi ladies and gents. Hoping someone can help me out with the performance of this animation in Safari. I built a site for a friend and it works fine on Chrome, Firefox and Edge but on Safari it flashes towards the end of one of the animations in the timeline. I have no idea why. If anyone could give me some advice on how to fix this and any other tips to improve the performance, i'd really appreciate it 😘 https://theswirlytrain.com Here is a video example of what is happening. // start animation at top of page function scrollTop() { if ('scrollRestoration' in history) { history.scrollRestoration = 'manual'; } window.scrollTo(0,0); } const tl = gsap.timeline({ defaults: { ease: 'power3.out' }, onStart: scrollTop }); tl.set('article', {autoAlpha: 1}); tl.from('.home .artwork .elementor-widget-container', 3, { scale: 8, autoAlpha: 0, delay: 0.3}); tl.from('.home .elementor-button, .signup-form, .release-details', 1, {autoAlpha: 0, y: 40, stagger: 0.4, delay: -1}); tl.from('header', 1, {autoAlpha: 0, delay:-0.5}); tl.from('.moving-text', 3, {autoAlpha: 0, scale:1.2, x: 100, delay:-0.5});
  5. 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. Since launching MorphSVGPlugin, we've made a bunch of improvements and exposed several new features. Here are the highlights... The challenge Before we dive into solutions, it helps to understand the tasks that MorphSVGPlugin must perform in order to work its magic: Convert the path data string into pure cubic Beziers Map all of the segments between the start and end shapes (match them up), typically based on size and position If there are more segments in one than the other, fabricate new segments and place them appropriately Subdivide any segments with mis-matching point quantities If a shapeIndex number isn't defined, locate the one that delivers the smoothest interpolation (shortest overall distance that points must travel). This involves looping through all the anchor points and comparing distances. Convert all the data back into a string Isolate the points that need to animate/change and organize a data structure to optimize processing during the tween. That may sound like a lot of work (and it is) but MorphSVGPlugin usually rips through it with blazing speed. However, if you've got a particularly complex path, you'll appreciate the recent improvements and the new advanced options: Performance tip #1: define a shapeIndex MorphSVGPlugin's default shapeIndex:"auto" does a bunch of calculations to reorganize the points so that they match up in a natural way but if you define a numeric shapeIndex (like shapeIndex:5) it skips those calculations. Each segment inside a path needs a shapeIndex, so multiple values are passed in an array like shapeIndex:[5,1,-8,2]. But how would you know what numbers to pass in? The findShapeIndex() tool helps for single-segment paths, what about multi-segment paths? It's a pretty complex thing to provide a GUI for. Typically the default "auto" mode works great but the goal here is to avoid the calculations, so there is a new "log" value that will act just like "auto" but it will also console.log() the shapeIndex value(s). That way, you can run the tween in the browser once and look in your console and see the numbers that "auto" mode would produce. Then it's simply a matter of copying and pasting that value into your tween where "log" was previously. For example: TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", shapeIndex:"log"}}); //logs a value like "shapeIndex:[3]" //now you can grab the value from the console and drop it in... TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", shapeIndex:[3]}}); Notes shapeIndex:"log" was added in MorphSVGPlugin version 0.8.1. A single segment value can be defined as a number or a single-element array, like shapeIndex:3 or shapeIndex:[3] (both produce identical results) Any segments that don't have a shapeIndex defined will always use "auto" by default. For example, if you morph a 5-segment path and use shapeIndex:2, it will use 2 for the first segment and "auto" for the other four. Performance tip #2: precompile The biggest performance improvement comes from precompiling which involves having MorphSVGPlugin run all of its initial calculations listed above and then spit out an array with the transformed strings, logging them to the console where you can copy and paste them back into your tween. That way, when the tween begins it can just grab all the values directly instead of doing expensive calculations. For example: TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", precompile:"log"}}); //logs a value like precompile:["M0,0 C100,200 120,500 300,145 34,245 560,46","M0,0 C200,300 100,400 230,400 100,456 400,300"] //now you can grab the value from the console and drop it in... TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", precompile:["M0,0 C100,200 120,500 300,145 34,245 560,46","M0,0 C200,300 100,400 230,400 100,456 400,300"]}}); As an example, here's a really cool codepen by Dave Rupert before it was precompiled: http://codepen.io/davatron5000/pen/meNOqK/. Notice the very first time you click the toggle button, it may seem to jerk a bit because the entire brain is one path with many segments, and it must get matched up with all the letters and figure out the shapeIndex for each (expensive). By contrast, here's a fork of that pen that has precompile enabled: http://codepen.io/GreenSock/pen/MKevzM. You may noticed that it starts more smoothly. Notes precompile was added in MorphSVGPlugin version 0.8.1. Precompiling only improves the performance of the first (most expensive) render. If your entire morph is janky throughout the tween, it most likely has nothing to do with GSAP; your SVG may be too complex for the browser to render fast enough. In other words, the bottleneck is probably the browser's graphics rendering routines. Unfortunately, there's nothing GSAP can do about that and you'll need to simplify your SVG artwork and/or reduce the size at which it is displayed. The precompiled values are inclusive of shapeIndex adjustments. In other words, shapeIndex gets baked in. In most cases, you probably don't need to precompile; it's intended to be an advanced technique for squeezing every ounce of performance out of a very complex morph. If you alter the original start or end shape/artwork, make sure you precomple again so that the values reflect your changes. Better segment matching In version 0.8.1, there were several improvements made to the algorithm that matches up corresponding segments in the start and end shapes so that things just look more natural. So even without changing any of your code, loading the latest version may instantly make things match up better. map: "size" | "position" | "complexity" If the sub-segments inside your path aren't matching up the way you hoped between the start and end shapes, you can use the map special property to tell MorphSVGPlugin which algorithm to prioritize: "size" (the default) - attempts to match segments based on their overall size. If multiple segments are close in size, it'll use positional data to match them. This mode typically gives the most intuitive morphs. "position" - matches mostly based on position. "complexity" - matches purely based on the quantity of anchor points. This is the fastest algorithm and it can be used to "trick" things to match up by manually adding anchors in your SVG authoring tool so that the pieces that you want matched up contain the same number of anchors (though that's completely optional). TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", map:"complexity"}}); Notes map is completely optional. Typically the default mode works great. If none of the map modes get the segments to match up the way you want, it's probabaly best to just split your path into multiple paths and morph each one. That way, you get total control. Animate along an SVG path The new MorphSVGPlugin.pathDataToBezier() method converts SVG <path> data into an array of cubic Bezier points that can be fed directly into a BezierPlugin-based tween so that you can essentially use it as a motion guide. Watch the video Demo See the Pen pathDataToBezier() docs official by GreenSock (@GreenSock) on CodePen. Morph back to the original shape anytime If you morph a path into various other shapes, and then you want to morph it back to its original shape, it required saving the original path data as a variable and feeding it back in later. Not anymore. MorphSVGPlugin records the original path data in a "data-original" attribute directly on the element itself, and then if you use that element as the "shape" target, it will automatically grab the data from there. For example: TweenMax.to("#circle", 1, {morphSVG:"#hippo"}); //morphs to hippo TweenMax.to("#circle", 1, {morphSVG:"#camel"}); //morphs to camel TweenMax.to("#circle", 1, {morphSVG:"#circle"}); //morphs back to circle. Conclusion We continue to be amazed by the response to MorphSVGPlugin and the creative ways we see people using it. Hopefully these new features make it even more useful. How do I get MorphSVGPlugin? If you're a "Shockingly Green" or "Business Green" Club GreenSock member, just download the zip from your account dashboard or the download overlay on GSAP-related page on this site. If you haven't signed up for Club GreenSock yet, treat yourself today.
  6. 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. There are some interesting (and surprising) performance implications of using CSS animations that aren't widely known. I stumbled across a few of them while running tests for a customer in the advertising industry who is pushing to have GSAP adopted as the standard, so I recorded a screencast explaining what I found. I figured it was worth sharing: Summary Timeline recordings in Chrome Dev Tools don't show the overhead involved with CSS animation of transforms, so people often misinterpret the [lack of] data. Recordings look "clean" with CSS and "dirty" with JS which leads to faulty conclusions about performance. CSS animations of transforms used twice as much CPU compared to JS according to Chrome's task manager. CSS animations caused the main thread to bog down more than using JavaScript animations. User interaction is typically handled on the main thread, making things feel sluggish to the user. It is especially costly if you animate transforms along with almost any other property at the same time. Webkit browsers have synchronization problems. JavaScript was faster than CSS animations on every device that I ran this test on – the only exception was animating transforms in Webkit browsers (and then there's that heavy cost on the main thread and sync problems). In order to independently control the timing/easing of transform components (rotation, scale, skew, position) in CSS, you must create a DOM node for each which negatively impacts performance. With JavaScript, no such workarounds are necessary. (see note below) I love Dev Tools - I'm not knocking it at all. These things are just tough to measure. Do your own tests! Don't put too much faith in Dev Tools or my tests. Use your eyes because ultimately perception is what matters to end users. Smooth movement and responsive UI are both important. Links Raw Codepen test Google's Paul Lewis addresses CSS vs. JS Animations A great article about hardware accelerated CSS by Ariya Hidayat Why GSAP? - a practical developer's guide UPDATE: After recording the video, I did some more tests that showed that one of the biggest contributors to the slowdowns in the pure CSS version was the fact that multiple elements had to be nested in order to accomplish the independent transform component controls. In other words, staggering the start/end times (or easing) of rotation, scale, and position is practically impossible in pure CSS unless you nest things like that, but there's a relatively significant performance tradeoff. When nesting could be avoided, pure CSS animation of only transforms did appear smoother on webkit browsers under heavy pressure and it was basically indistinguishable from optimized JS animations under all other levels of pressure.
  7. No need to worry. Tweens and timelines are automatically made eligible for garbage collection (gc) when appropriate (typically when they finish but if you maintain a reference to an instance so that you can restart it later, for example, it won’t be gc’d out from under you). Basically the system manages gc for you and generally cleans up after itself.
  8. 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. With the release of iOS 7, I was anticipating some big leaps forward in browser performance. What I found was quite surprising. Is anyone else experiencing the same thing? Here's a quick [and very casual] video showing what I discovered: A lot of people in the industry talk about the benefits of using CSS transitions because they're so much faster, especially with transforms (scale/translate/rotate) on mobile devices. What happened? Why is Zepto (which uses CSS transitions) so much slower? GSAP's performance remains solid in iOS 7 (far better than jQuery and other libraries), but CSS transitions fall flat on their face (at least with transforms). Can anyone shed some light on what's happening? Are you seeing the same results in iOS 7? Also, is anyone else seeing worse performance when altering the scrollTop or scrollLeft of DOM elements? Useful links Speed test Draggable Demo CSS Transitions/Animations vs. GSAP Cage Match jQuery vs. GSAP Cage Match Why GSAP? A practical guide for developers UPDATE: Apple reached out to us and acknowledged the apparent bug and said they're working on a fix. (Thanks Apple)
  9. 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. Update: don't miss our guest post on css-tricks.com, Myth Busting: CSS Animations vs. JavaScript which provides some additional data, visual examples, and a speed test focused on this topic. Ever since CSS3 "transitions" and "animations" were introduced, they have been widely lauded as the future of animation on the web. It often seems like all the "cool kids" are talking about them. Should you jump on the bandwagon? Is JavaScript animation headed for extinction? How does the new GreenSock Animation Platform (GSAP) fare when it steps into the ring and faces off against the hyped-up tag-team of CSS3 transitions & animations? Does GSAP have the chops to hold its own? Let's find out. Ready...FIGHT! Performance One of the most common arguments in favor of CSS3 animations has been that they're hardware accelerated, thus outperform any JavaScript-based equivalent. The theory is that if you define your transitions/animations directly in css, the browser can worry about all the calculations behind the scenes and tap into hardware and native code to execute them. Sounds awesome. Unfortunately it's not quite that clean. Only certain properties are hardware-accelerated (like 3D transforms and opacity - mostly ones that don't affect document flow) and different browsers handle things differently. Plus every comparison we saw on the web pitted CSS3 transitions against jQuery, but GSAP is up to 20 times faster than jQuery. In our real-world tests, we saw drastic differences in performance among the various browsers and when tested head-to-head against GSAP, CSS3 animations were usually slower! Weird. As expected, however, 3D transforms were indeed faster under heavy stress although in most situations you'd never notice a difference. GSAP is extremely optimized. UPDATE (2015-01-05): There are some interesting (and surprising) performance implications of using CSS animations that aren't widely known. Here's a screencast that shows how Dev Tools doesn't report the overhead involved with CSS animations, some synchronization problems, and how they can drag down the main thread performance more than JS. To see a simple comparison for yourself, select the "Zepto" engine in the speed comparison because it uses CSS3 transitions for its animations, and then compare it to GSAP. Beware that the fps (frames per second) counter in the lower right corner isn't always accurate in some browsers (like recent versions of Safari) when using CSS3 transitions because requestAnimationFrame events [incorrectly] get dispatched even when the screen is clearly not being updated. So the animation may actually be running at a very jerky 10fps, yet 50+ requestAnimationFrame cycles are being triggered by the browser! This exposes another flaw in CSS3 transitions - there's no way to know when updates truly occur. There's only a "complete" event fired at the end of the transition/animation. If anyone knows how to get a more accurate fps counter in Safari while using CSS3 transitions, please let us know. Another performance issue to note in the speed comparison is the clumping that occurs with many engines (including Zepto) under heavy stress, where the stars begin pulsing out in rings instead of a nicely dispersed field. Even though GSAP was faster than CSS3 transitions in the majority of our real-world tests, it's still true that 3D transforms and opacity tweens are faster with CSS3 transitions and it's possible that browsers will be able to further tap into hardware acceleration in the future, so we'll call this round a tie. Feel free to build your own tests to see how things compare in your workflow. Performance winner: TIE Controls This is one of the major weak spots for CSS transitions (its "glass jaw" of sorts). Let's say you invest the time in writing a bunch of css for a whiz-bang animation and then you need to control the whole thing - good luck with that. It is virtually impossible. GSAP's object oriented architecture allows you to pause, resume, reverse, restart, or seek to any spot in any tween. Even adjust timeScale on the fly for slow motion or fastforward effects. Place tweens in a timeline with precise scheduling (including overlaps or gaps) and then control the whole thing just like it's a single tween. All of the easing and effects remain perfectly intact as you reverse, adjust timeScale, etc. (with CSS transitions, easing flip-flops upon reverse). You can even kill individual portions of a tween anytime (like if a tween is controlling both "top" and "left" properties, you can kill "left" while "top" continues). Put labels in a timeline to mark important spots and seek() to them anytime. Imagine trying to build the example below using CSS transitions. It would be virtually impossible. With GSAP, it's easy. In fact, all of the animation is done with 2 lines of code. Drag the scrubber, click the buttons below, and see how easy it is to control the sequenced animation. Controls winner: GSAP Tweenable Properties Both competitors can animate transforms (2D and 3D), colors, borderRadius, boxShadow, and pretty much every important property, but there's one key shortcoming of CSS - you cannot animate individual transforms distinctly! For example, try rotating an object and then halfway through that animation, start scaling it with a different ease and finish at a different time. Since all transforms (scaleX, scaleY, rotation, rotationX, rotationY, skewX, skewY, x, y, and z) are all mashed into one "transform" property, it's virtually impossible to handle them distinctly. GSAP not only works around this limitation, but it also allows you to do advanced things like animate along Bezier paths or do momentum-based motion (with ThrowPropsPlugin) or relative tweens or animate the scroll position or do directional rotation or physics-based motion, etc. Plus GSAP can animate any numeric property of any object, not just DOM elements. Do you really want to use one toolset (CSS) for animating DOM elements and then have to switch to a completely different toolset and syntax when you do canvas-based animation? GSAP handles both consistently. CSS transitions and animations just can't compete here. Tweenable properties winner: GSAP Workflow When you're creating fun and interesting animations, workflow is critical. You need to be able to quickly build sequences, stagger start times, overlap tweens, experiment with eases, leverage various callbacks and labels, and create concise code. It would be great to modularize your code by creating functions that each spit back an animation object (tween or timeline) which can be inserted into another timeline at a precise time. You need a flexible, powerful system that lets you experiment without wasting hours. GSAP wipes the floor with CSS transitions in this round. Anyone who has attempted an ambitious project with CSS3 transitions/animations will attest to the fact that they tend to get very cumbersome and verbose. Experimenting with timing and fine-tuning details can get extremely tedious especially when dealing with all the browser prefixes. GSAP CSS3 transitions = supported = unsupported Flexible object-oriented architecture that allows animations to be nested inside other animations as deeply as you want Supported Unsupported Concise code that doesn't require vendor prefixes Supported Unsupported Create sequences (even with overlapping animations) that auto-adjust as you insert/remove/change intermediate pieces of animation (makes experimenting MUCH easier) Supported Unsupported Accommodate virtually any ease including Bounce, Elastic, SlowMo, RoughEase, SteppedEase, etc. Supported Unsupported Animate things into place (backwards) with convenience methods like from() and staggerFrom() Supported Unsupported Callbacks for when an animation starts, updates, completes, repeats, and finishes reversing, plus optionally pass any number of parameters to those callbacks Supported Unsupported Place labels at specific times in a sequence so that you can seek() there (and/or insert animations there) Supported Unsupported Animate any numeric property of any JavaScript object, not just DOM elements (great for canvas-based animation). Supported Unsupported Workflow winner: GSAP Compatibility CSS transitions simply don't work in older browsers, even Internet Explorer 9. GSAP works in all browsers (although some particular features may be disabled, like 3D transforms in IE8). Once again, this round was no contest. GSAP can even do 2D transforms like rotation, scaleX, scaleY, x, y, skewX, and skewY all the way back to IE6 including transformOrigin functionality! Plus it works around scores of other browser issues so that you can focus on the important stuff. Safari's 3D transformOrigin bug? No problem. Firefox's flashing 3D elements bug? No worries. Inconsistency in IE's backgroundPosition values? GSAP has you covered. Vendor prefixes? Nah, GSAP adds 'em for you when necessary. Compatibility winner: GSAP Popularity CSS3 transitions have been talked about (and used) for years all over the web whereas GSAP is relatively new. It can't match CSS3 transitions' popularity. As clients start pushing for more aggressive animations and HTML5 games proliferate and operating systems become very JavaScript-friendly, the balance may very well shift quickly. For now, though, this round goes squarely to CSS transitions. Popularity winner: CSS3 transitions Conflict management What happens if a particular set of properties (like "left" and "top") are animating and then you need to redirect one of those to a different value (like "left" to 100px instead of 300px) using a different ease and duration? With CSS transitions, it's a very complex process. With GSAP, it's simple and automatic. In fact, there are several overwrite modes you can choose from. Conflict management winner: GSAP Support There are numerous places on the web where you can ask the community your CSS transitions-related questions, but GSAP has dedicated support forums where there's rarely a question that remains unanswered for more than 24 hours. GreenSock's forums are manned by paid staff (including the author of the platform), so you're quite likely to get solid answers there. Add to that the fact that GreenSock has a track record of being much more agile in terms of squashing bugs and releasing updates than browsers do for CSS3 transitions, so GSAP gets the upper hand here. Support winner: GSAP Expandability GSAP employs a plugin architecture, making it relatively easy to add features and custom animation properties but CSS transitions have no such equivalent. You're stuck with what the browsers decide to offer. In addition to CSSPlugin, GSAP already has plugins like ScrollToPlugin for scrolling to specific window or div scroll positions, BezierPlugin for animating along Bezier curves, ThrowPropsPlugin for momentum-based motion, and RaphaelPlugin, EaselPlugin, and KineticPlugin for those libraries (Raphael, EaselJS, and KineticJS). Plus there are physics-based plugins like Phyics2DPlugin and PhysicsPropsPlugin as well as a fun ScrambleTextPlugin for Club GreenSock members. More plugins are on their way, and you can create your own too. Expandability winner: GSAP Learning resources Again, the popularity of CSS3 transitions trumps anything GSAP could throw at it right now. There are lots of tutorials, videos, and articles about CSS3 transitions whereas GSAP is new to the game. GreenSock is being aggressive about putting together solid resources (like the Jump Start tour) and the community is crankin' out some great articles and videos too, but CSS3 transitions score the win in this round. Learning resources winner: CSS3 TRANSITIONS Price & license Both CSS3 transitions and GSAP are completely free for almost every type of usage. GSAP allows you to edit the raw source code to fix bugs (if that's something you need to do), but there's no way to edit the source code that drives CSS3 transitions. Then again, there's no special license required to use them either. If you plan to use GSAP in a product/app/site/game for which a fee is collected from multiple customers, you need the commercial license that comes with "Business Green" Club GreenSock memberships (one-off commercial projects don't require the special license). It's actually a more business-friendly license in many ways than a typical open source license that offers no warranties or backing of any kind or imposes code sharing or credit requirements. GreenSock's licensing model provides a small funding mechanism that benefits the entire user base because it empowers continued innovation and support, keeping it free for the vast majority of users. See the licensing page for details. Although there are some clear benefits of GreenSock's model, we'll give this round to CSS3 transitions because using them is technically "free" in more scenarios than GSAP. Price & license winner: CSS3 TRANSITIONS File size This is a tricky round indeed because GSAP requires inclusion of at least 1 JavaScript file whereas CSS3 transitions leverage native code in the browser, but the code you'd have to write to accomplish the same thing in CSS3 animations or transitions is often far more verbose, offsetting the kb savings. For example, let's take a relatively simple sequenced animation (see codepen or jsfiddle? GSAP code: var tl = new TimelineLite(); tl.staggerFrom('.box', 0.5, {opacity:0, scale:0, rotation:-180}, 0.3) .staggerTo('.box', 0.3, {scale:0.8}, 0.3, 0.7); This type of thing is impossible with CSS3 transitions, but it can be done with CSS3 animations as long as we give each element its own class name or ID. Let's take a look at the CSS code (see codepen or jsfiddle? Equivalent CSS3 Animation: .animated { -webkit-animation-fill-mode: both; -moz-animation-fill-mode: both; animation-fill-mode: both; -webkit-animation-duration: 1s; -moz-animation-duration: 1s; animation-duration: 1s; } @-webkit-keyframes introAnimation { 0% { -webkit-transform: scale(0) rotate(-180deg) ; opacity: 0; } 50% { -webkit-transform: scale(1) rotate(0deg) ; opacity: 1; } 70% { -webkit-transform: scale(1) rotate(0deg); } 100% { -webkit-transform: scale(0.8) rotate(0deg); } } @-moz-keyframes introAnimation { 0% { -moz-transform: scale(0) rotate(-180deg); opacity: 0; } 50% { -moz-transform: scale(1) rotate(0deg); opacity: 1; } 70%{ -moz-transform: scale(1) rotate(0deg); } 100% { -moz-transform: scale(0.8) rotate(0deg); } } @keyframes introAnimation { 00% { transform: scale(0) rotate(-180deg); opacity: 0; } 50% { transform: scale(1) rotate(0deg); opacity: 1; } 70%{ transform: scale(1) rotate(0deg); } 100% { transform: scale(0.8) rotate(0deg); } } .introAnimation { -webkit-backface-visibility: visible !important; -webkit-animation-name: introAnimation; -moz-backface-visibility: visible !important; -moz-animation-name: introAnimation; backface-visibility: visible !important; animation-name: introAnimation; } .two { -webkit-animation-delay: 0.3s; -moz-animation-delay: 0.3s; animation-delay: 0.3s; } .three { -webkit-animation-delay: 0.6s; -moz-animation-delay: 0.6s; animation-delay: 0.6s; } .four { -webkit-animation-delay: 0.9s; -moz-animation-delay: 0.9s; animation-delay: 0.9s; } .five { -webkit-animation-delay: 1.2s; -moz-animation-delay: 1.2s; animation-delay: 1.2s; } .six { -webkit-animation-delay: 1.5s; -moz-animation-delay: 1.5s; animation-delay: 1.5s; } .seven { -webkit-animation-delay: 1.8s; -moz-animation-delay: 1.8s; animation-delay: 1.8s; } .eight { -webkit-animation-delay: 2.1s; -moz-animation-delay: 2.1s; animation-delay: 2.1s; } .nine { -webkit-animation-delay: 2.4s; -moz-animation-delay: 2.4s; animation-delay: 2.4s; } As you can see, the CSS3 code is more than 10 times longer! And what if you want to have the entire sequence repeat 3 times? Good luck with that in CSS - you can set an animation-iteration-count but it only applies to each individual element, so it doesn't give us the effect we're after. And what if you want to experiment with the easing or offsets/delays or rotational values? It is quite cumbersome to say the least, even if you use sass or something like that. With GSAP, it's simple. If you only need very simple animations/transitions, CSS3 would deliver smaller file sizes, but once you start getting more aggressive and expressive with your animations, the scales shift quickly and GSAP becomes more economical. The other thing to keep in mind is that GSAP's JS file(s) are typically cached by the browser, so the savings page-to-page is much larger since the code you write on each page is far more concise. In other words, think of how much js/css the browser must actually request from the server over the course of your users' multi-page visit to your site. File size winner: TIE Flexibility Let's face it: basic tweening is pretty straightforward for any system, but it's really the details and advanced features that make a robust platform shine. GSAP crushes CSS3 transitions and animations when it comes to delivering a refined, professional-grade tool set that's truly flexible. Here are just a few of the conveniences baked into GSAP: Tween any numeric property of any object. Optionally round values to the nearest integer to make sure they're always landing on whole pixels/values. Animate along Bezier curves, even rotating along with the path or plotting a smoothly curved Bezier through a set of points you provide (including 3D!). GSAP's Bezier system is super flexible in that it's not just for x/y/z coordinates - it can handle ANY set of properties. Plus it will automatically adjust the movement so that it's correctly proportioned the entire way, avoiding a common problem that plagues Bezier animation systems. You can define Bezier data as Cubic or Quadratic or raw anchor points. Animate any color property of any JavaScript object (not just DOM elements). Define colors in any of the common formats like #F00 or #FF0000 or rgb(255,0,0) or rgba(255,0,0,1) or hsl(30, 50%, 80%) or hsla(30, 50%, 80%, 0.5) or "red". Set a custom fps (frames per second) for the entire engine (the default is 60fps). All tweens are perfectly synchronized (unlike many other tweening engines). Use the modern requestAnimationFrame API to drive refreshes or a standard setTimeout (the default is requestAnimationFrame with a fallback to setTimeout) Tons of easing options including proprietary SlowMo, RoughEase, and SteppedEase along with all the industry standards Animate css style sheet rules themselves with CSSRulePlugin Animate the rotation of an object in a specific direction (clockwise, counter-clockwise, or whichever is shortest) by appending "_cw", "_ccw", and "_short" to the value. You can tween getter/setter methods, not just properties. For example, myObject.getProp() and myObject.setProp() can be tweened like TweenLite.to(myObject, 1, {setProp:10}); and it will automatically recognize that it's a method and call getProp() to get the current value when the tween starts. Same for jQuery-style getters/setters that use a shared method like myObject.prop(). You can even tween another tween or timeline! For example, TweenLite.to(otherTween, 1, {timeScale:0.5}) would animate otherTween.timeScale to 0.5 over the course of 1 second. You can even scrub the virtual playhead of one tween/timeine with another tween by animating its "time". Flexibility winner: GSAP Conclusion Despite the hype surrounding CSS3 transitions and animations, they just aren't well-suited for professional-grade animation tasks. They did manage to win a few rounds in this match but ultimately GSAP man-handled them, sending them running from the ring like scared sissies. Of course we're slightly biased, but check out the facts for yourself. Kick the tires. Audition GSAP on your next project. See how it feels once you get past the initial learning curve. If you only need simple fades or very basic animation in modern browsers, CSS3 transitions are probably just fine. However, what happens when your client wants to do something more expressive? What if browser compatibility becomes an issue? Why not build on a solid foundation to begin with so that you don't find yourself having to rewrite all your animation code? If you want professional-grade scripted animation, look no further. To get started fast, check out our Jump Start tour. Recommended reading: Main GSAP JS page Why GSAP? A practical guide for developers Jump Start: GSAP JS jQuery vs GSAP: cage match 3D Transforms & More CSS3 Goodies Arrive in GSAP JS Speed comparison Explanation of CSS3 transitions, transforms and animations P.S. A rant about where animation logic belongs: We can't put this post to bed without mentioning a beef we've got with the whole concept of putting all your animation logic in css. Ever since the <blink> tag, there has been this tendency for browser vendors to offer developers these nifty "conveniences" that end up encouraging them to mix markup and/or style rules with behavioral logic. Is that really a good idea? One of the wonderful things about the modern web is that we've got this lovely separation between markup, presentation/styling, and behavioral logic (at least that's the goal). Should we be blurring the line like this? Isn't JavaScript the logic layer that should be handling state changes, application logic, reaction to user interaction (which often includes animation), etc.? Some may claim "But putting animation in css is great because that way if the user has JavaScript disabled, the animations still work!" Do you really think users of the modern web can turn off JavaScript and expect to browse the web with great results? Is that who you're targeting for a rich experience? And if they turned off JavaScript, might they have done so specifically to avoid annoying animations? Is it really helping to shift animation logic into css where they can't turn it off? In the web of yesteryear, animations were quite simplistic; fade this, slide that. Done. Anything more aggressive was relegated to a plugin like Flash which afforded incredible richness and complexity in terms of animation. But today, clients want that sort of expressiveness directly in the browser. It needs to work on mobile devices. It's no longer about simple fade-ins or sliding an image across the screen. CSS3 transitions fit the old mentality well, but not the new one. CSS3 animations technically provide more flexibility but they fall miserably short and they still force behavioral logic into the style layer. And to use them effectively, we still need JavaScript to at least swap classes and trigger things. From a development and debugging standpoint, when I apply a class to an element how would I know if that will trigger an animation or transition or neither? Should I have to keep bouncing back and forth between css and JS to manage behavioral logic related to animations? Maybe we're just ill-informed and there are some fantastic reasons for putting behavioral logic like animation into the css layer, but one thing seems pretty clear: the current way that developers have to build all but the simplest css animation leaves a LOT to be desired. The API is terribly limiting and clunky. Let's move the web forward. Let's make animation fun and flexible. Let's keep behavioral logic and style rules distinct. Let's leverage the incredible flexibility of JavaScript. If we've misrepresented anything here or if you want to weigh in with your opinion about where behavioral logic like animation belongs, feel free to post your comment below. If you're someone who has attempted an aggressive animation task with CSS3 transitions/animations as well as GSAP, we'd love to hear how you felt they compared.
  10. Maybe someone can help me out. I have performance problems loading an GSAP animation. The animation is this: Add SVG to div, and the SVG will follow a data path in SVG d: coordinates. It works fine on desktop, and only sometimes on Ipad / Iphone. The problem is that the SVG is moving very slowly, like the data path is still being loaded. I tracked the fps, which topped around 100 for Ipad. How to experience the problem: Click on the down arrow to go below water surface. Then click on the whale icon. The whale SVG should appear from left to right, and follow a data path for 20 seconds. If the whale moves smoothly, then all is good. But if the whale is moving very slowly, and in staggering movements, then the error must be performance problems ?
  11. Hello there! I'm a bit newbie in a GSAP animation exactly. And I'll start with a simple example to understand my expectations. For example, if I'll create the element like this const elem = document.createElement("div"); it is not in DOM for now, but I can apply animation on it so far TweenMax.to(elem, 1, { x: 300 }); and it will start immediatly. So, when this element will be appended into DOM (after 1 sec passed), it will have its `transform: translateX(300px);` If this element appends while tweening we'll see it moving from some middle point. The very simple example is in CodePen applied. Is there a way to make some performance on elements, that are not in DOM for right now, i.e. hold the animation until the element appears on the screen? Some kind of holding animation request until appending or smth. similar. Hope, my explanation is well. Best regards, Nick Rimer UPD: I solved this case with a combination of `pause` property and `document.body.contains(elem)`. Saving animation first: const anim = TweenMax.to(elem, 1, { x: 300, paused: !document.body.contains(elem) }); Run animation when element will appear: anim.play(); But I don't know if this solution is awful/great/the best. Maybe you'll find the most efficient and elegant way. CodePen was updated. UPD2: Want to point out that the aim is to understand are there any performances on start of the animation I not needed to start right now? I really don't wanna to start even calculate something, if the animation starts not in time (there may be several animation at one time or smth. else). But to start animate, when the element appears. So I don't really understand will the solution with `paused: true` helps or not.
  12. Hello, I am pretty new to GSAP and so I may be doing something wrong, but I am having a performance issue with multiple back and forths animating three.js objects and then reversing them. As you can see on my project (linked below) when you click the three.js objects and then click the back button all the animations work fine. But the more you click them, the slower they start to become and the longer the reverse animation takes on the objects and on the text. Now I am not sure if I set it up wrong and its just an issue with my code, or whether its a performance issue. Can someone please see my GSAP code below and see if they can pin point what might be happening? Here is a link to my project: http://jacobtruax.info/ Code for the Tweening: const tl = new TimelineLite() const tlFNUP = new TimelineLite() const tlOld = new TimelineLite() const tlAlex = new TimelineLite() const tlCam = new TimelineLite() TweenMax.set(backTag,{autoAlpha:0}); TweenMax.set(footerTag, {autoAlpha:0}); TweenMax.set(moreTag, {autoAlpha:0}); function onDocumentMouseDown(event) { const intersections = raycaster.intersectObjects(objects) if (intersections.length > 0){ if(projectHov){ tl.play(); tl.add( TweenMax.to(footerTag, .5, {delay: 1, autoAlpha: 1,})); tl.to(backTag, 1, { delay: 1.25, autoAlpha:1, }, 0); tl.to(moreTag, 1, { delay: 1.35, autoAlpha: 1, }, 0); } if (intersections[0].object == old ) { if(projectHov){ tlOld.play(); projectHov = false tlOld.add(TweenMax.to(old, 1.5, {three:{scaleX: 2.5, scaleY: 2.5, x:0, y:0, z:0}, ease:Power2.easeInOut})); tlOld.to(fnup, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlOld.to(alex, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlOld.to(cam, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlOld.to(mirrorCube, 1, {three:{y:-400, opacity: 0 }, ease:Power2.easeInOut}, 0); groupRotate = false } } if (intersections[0].object == fnup) { if(projectHov){ tlFNUP.play(); projectHov = false tlFNUP.add(TweenMax.to(fnup, 1.5, {three:{scaleX: 2.5, scaleY: 2.5, x:0, y:0, z:0 }, ease:Power2.easeInOut})); tlFNUP.to(old, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlFNUP.to(alex, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlFNUP.to(cam, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); groupRotate = false tlFNUP.to(mirrorCube, 1, {three:{y:-400, opacity: 0 }, ease:Power2.easeInOut}, 0); } } if (intersections[0].object == cam) { if(projectHov){ tlCam.play(); projectHov = false tlCam.add(TweenMax.to(cam, 1.5, {three:{scaleX: 2.5, scaleY: 2.5, x:0, y:0, z:0}, ease:Power2.easeInOut})); tlCam.to(fnup, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlCam.to(alex, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlCam.to(old, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); oldRotate = false groupRotate = false tlCam.to(mirrorCube, 1, {three:{y:-400, opacity: 0 }, ease:Power2.easeInOut}, 0); } } if (intersections[0].object == alex) { if(projectHov){ tlAlex.play(); projectHov = false tlAlex.add(TweenMax.to(alex, 1.5, {three:{scaleX: 2.5, scaleY: 2.5, x:0, y:0, z:0}, ease:Power2.easeInOut})); tlAlex.to(fnup, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlAlex.to(cam, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); tlAlex.to(old, 1, {three:{y:-4000, opacity: 0 }, ease:Power2.easeInOut}, 0); oldRotate = false groupRotate = false tlAlex.to(mirrorCube, 1, {three:{y:-400, opacity: 0 }, ease:Power2.easeInOut}, 0); } } } backTag.addEventListener("click", function() { projectHov = true groupRotate = true tlOld.reverse(); tlAlex.reverse(); tlCam.reverse(); tlFNUP.reverse(); tl.reverse(); })
  13. FAKS

    GSAP vs CSS

    Hi everyone, I wanted to reply this post -> http://greensock.com/css-performance But I don't know why I can't leave a message, even if I'm logged in... So I'll share my opinion here I'm working on a game webapp (HTML5/CSS/JS), running on desktop browsers, smartphone, tablet and also into a native IOS app (webview) built with Cordova. In this webapp, like in every games, there is of course transitions between pages, popup and dialog apparition, drag and drop functions, etc... there is also transitions/animations on elements such as div, svg, png from the DOM during the game. During my development process, I was looking for the best way to animate those elements to get the best visual effect during transitions, tween, bouncing effect, apparition effect, etc. I was focusing on this idea "the user should NOT see the difference between my webapp and a real native app". I wanted every transitions/animations look smooth and great. I know GSAP since 2010 so this was my first idea. GSAP is really the most convenient JS library that I know to animate. I have nothing to say on that point. But, during my test on different devices, I noticed that large transitions such as fade on the entire screen, dialog and popup bouncing, opacity apparition was laggy on smartphone and tablet (on desktop browser it was great). So I did some research and test. After reading lot of post about CSS vs JS I tried by myself to recode all those laggy transitions only with CSS rules. The result was surprising because those new transitions was great, no lag, very fluid, better than with GSAP. Then I found this article -> http://greensock.com/css-performance I tried the CodePen linked -> http://codepen.io/GreenSock/full/2a53bbbcd47df627f25ed1b74beb407d/ On my laptop I can't see any difference (I'm not talking about pure performance and FPS benchmark, I'm only talking about visual feeling, looking for something fluid, without lag). But did you try this CodePen on tablet and smartphone? The difference is huge. CSS transitions look really better, fluid without any lag during transition. I did test on iPad Pro, iPad Air, iPad 3, iPhone 5, iPhone 6... Each times I set the Quantity at 2000 and I can see a huge difference. CSS looks much better. Of course coding complex animation with pure CSS rules is awful, so if I could get the same result with GSAP I'll use it for sure. And you guys? Did you encountered the same issue with smartphone and tablet? Any opinion or comment are welcome! Thanks!
  14. Hi, I’m relatively new to GSAP and am loving the experience so far - great job all involved! I have a quick question about performance and best practice when making a few animations at the same time. I have one point in my web site process where I want to have a number of elements change state in sequence. I have added all of these to a timeline and it performs relatively well. When running it there is a slight performance hit, I’m guessing because I’m changing a good number of properties. When doing this, is it good practice to add all of the changes to a timeline, or run them as separate TweenMax.to statements? I’ve included my statement here although the related html is large and would be tough to include in codepen. Can anybody spot anything blatantly wrong than I’m doing, or suggest any improvements on what I have shared to help speed smooth this sequence out? For reference, ctlTopCurve and ctlModel are SVG controls, imgHeader is an image and the rest of the controls are Div’s. Thanks in advance for your help, Al. var tl = new TimelineLite(); $("#modelSwipeLayer").css('display', 'none'); $("#ctlTopCurve").css('display', 'block'); $("#ctlTopCurve").css('z-index', '1'); $("#ctlHeader").css('height', '40%'); $("#imgHeader").css('marginLeft', $(window).width()); $("#imgHeader").attr("src", "/Content/Images/hero-image-3.jpg"); $("#imgHeader").css('z-index', 0); $("#IndividualDashCompareDescriptionContainer").css('display', 'block'); $("#IndividualDashMeasureDescriptionContainer").css('display', 'block'); $("#imgHeader").css("opacity", 0); $("#imgHeader").css("marginLeft", 0); //Hide the existing controls tl.to("#ctlModelInstructionContainer", 1.5, { autoAlpha: 0 }, 0) .to("#btnShowIndividualDash", 1.5, { autoAlpha: 0 }, 0) .to("#ctlModelZoneContainer", 0.5, { autoAlpha: 0 }, 0) .to("#ctlModelNavGestureHintContainer", 0.5, { autoAlpha: 0 }, 0) //Move the model up .to("#ctlModel", 1.5, { top: '280', height: $(window).width() - 70 }, 0) .to("#modelGraphicContainer", 1.5, { strokeWidth: 2 }, 0) .to("#ctlModel", 1.5, { rotation: 45 }, 0) //Show the action buttons .to("#btnShare", 1, { y: '-=44px' }, 0) .to("#btnCompare", 1, { y: '-=89px' }, 0) .to("#btnMeasure", 1, { y: '-=89px' }, 0) //Show the dash text .to("#IndividualDashCompareDescriptionContainer", 0.6, { autoAlpha: 1, top: parseInt($("#IndividualDashCompareDescriptionContainer").css('top')) - 30, delay: 0 }, 1.5) .to("#IndividualDashMeasureDescriptionContainer", 0.6, { autoAlpha: 1, top: parseInt($("#IndividualDashMeasureDescriptionContainer").css('top')) - 30, delay: 0.4 }, 1.5) //Slide in the header image .to("#imgHeader", 3, { autoAlpha: 1 }, 1.5);
  15. Hi Guys, I'm working on an animation that has the same structure as this pen. The effect I'm trying to achieve is Items flowing across the bottom right part of the screen at different speed. I've got 2 questions: 1) I can't understand why at the start of the animation the cats are sitting on the bottom of the container having given them a "top" of 100vh and they don't start from below that container. 2) I'm sure this is not a very performant way to animate this. Is there a better way to do it? Basically I don't care the order of the animations as long as they travel at 45degrees from bottom to the top right of the screen. Animations can occur randomly and they should be continuous. Hope that's clear, Thank you, Jp
  16. hi guys, I created a checkout that slides in from the side of the page. It all makes sense if you go to https://www.shinbyeong.com/ scroll down a bit and click on 'pre-order' on the bottom. So the first time you open the slider it's a bit chucky, then after performing more times it get's better. I guess that's some cache right there. I added a will-change: transform; on the elements affected. But I didn't see any improvements. When I use chrome dev tools to record the performance I'm not sure how to analyse it. I don't see large chunks of delayed properties (in ms). My question: Can I pre-cache this animation somehow? What else can I do to improve it? Here is the code, quite simple is my guess: .viewport--locked adds overflow hidden on outer element. .animate-out transitions some transforms on translateX. Nothing special, except that I fire 2 with a delay and try to create a parallax like effect. const showModal = () => { viewport.classList.add('viewport--locked') TweenLite.to(viewportOverlay, .5, { opacity: 1, onComplete: () => { checkoutContainer.classList.add('animate-out') TweenLite.to(checkout, .5, { xPercent: -100, ease: Power4.easeOut }) } }) } const closeModal = () => { checkoutContainer.classList.remove('animate-out') TweenLite.to(checkout, .45, { xPercent: 100, ease: Power4.easeIn, onComplete: () => { TweenLite.to(viewportOverlay, .25, { opacity: 0, onComplete: () => viewport.classList.remove('viewport--locked') }) } }) } buyButton.addEventListener('click', () => showModal()) checkoutClose.addEventListener('click', () => closeModal())
  17. Hi sorry if this has been asked already it's kind of a hard question to search for. I plan to have a pixi js scene of images for my website background where I'm often tweening images in and out of the scene, but in some scenarios tweening already offscreen images offscreen again so those tweens don't change any values. Do these unnecessary tweens affect performance? Is it better for performance to have conditional checks instead of 'no change in value' tweens? I don't think I will have performance issues either way but I wonder if gsap already has something built-in that automatically optimizes 'no change tweens' so that they don't have any affect on performance even if there are a large amount of them triggered all at the same time. Thanks.
  18. Hi, I am working on a project for university. I am using some animations on my site and on my desktop machine they all work fine and are smooth. But on my smartphone that's a whole different story. TweenMax.to(document.querySelector('.logo'), 0.4, {opacity: '0', ease: easeF}); TweenMax.to(elem.querySelector('.project_bg'), 0.4, {height: '40%', ease: easeF}); TweenMax.to(elem.querySelector('.project_shade'), 0.4, {height: '40%', ease: easeF}); TweenMax.to(elem.querySelector('.project_text'), 0.4, {top: '20%', ease: easeF}); TweenMax.to(elem.querySelector('.project_desc'), 0.4, {opacity: '0', ease: easeF}); TweenMax.to(document.querySelector('.project_total'), 0.4, {opacity: '0', ease: easeF}); TweenMax.to(document.querySelector('.close_button'), 0.4, {opacity: '1', ease: easeF}); TweenMax.to(elem.querySelector('.content'), 0.4, {opacity: '1', height: 'auto', y: window.innerHeight * 0.3, ease: easeF}); These animations in particular are very slow and stuttering on mobile devices. I don't know if these animations can be optimized but if yes it would help me alot if someone can explain me how. My easing function looks like this: easeF = new Ease(BezierEasing(.37,.01,0,.98)); Do I have to reduce the amount of animations or do I have to use a timeline (which I didn't at all until now)? URL: https://sftp.hs-furtwangen.de/~lautensc/gis/ Cheers and best regards!
  19. Hello, I'm trying to code a flickering animation, where a canvas and an image flicker on and off intermittently. I'm trying to get the timing of the flickering as accurate as possible: the canvas (multicoloured "mondrian" in the codepen) should be presented for 67 ms (4 frames at 60Hz) and the image ("stimulus" in the codepen) for 34ms (2 frames at 60Hz). I coded it using only autoalpha, drawing everything before the animation starts. The presentation times are recorded into an object called "vbl" in the codepen. On my macbook with chrome, animation works almost perfectly. But testing this animation on a few different setups (weaker windows machines, all chrome or firefox), I'm getting a considerable amount of mistiming: Especially in the first flickers in the sequence. Both the canvas and the image might be presented for too short or too long (0-100ms in range, though mean and median are close to wanted values). As timing is the most important issue for me, I am willing to use almost any trick to get it better. Any ideas? I'm fine with long (~0.7 second) loading times. Many thanks, Yaniv
  20. Hello, I made a little animation with gsap, and i really like how easy it is. But while it look great on y computer (gtx 1080), my coworker has heavy performance issues (imac 2007). Be both use the same browser (chrome), and he has better performances with last firefox build. I saw some people switching to canvas/paperjs, but i look like painfull. I'd like to know if the performance issue is about the number of animated elements (~432) or the way i build the timelinemax (in loop). Here is the pen : https://codepen.io/kaliel/full/XVbGvY/ Thanks
  21. In this demo I'm noticing a significant performance hit / choppiness when the animation first runs (click one one boxes). After that, every subsequent animation runs much smoother. I've noticed similar behavior in other projects when I'm manipulating the dom using tween max. Any ideas what can cause this / how to make it go away? Running this on a new macbook. Thanks.
  22. Zuriel

    FastDOM

    Can you tell me anything about FastDOM and if GSAP uses something similar or if you have ever heard of it, etc? I personally haven't heard anything about it until recently when someone recommended it to prevent some layout thrashing (something you see commonly with parallax animation where you are trying to move something based on scroll position, etc, etc). Whatever it is doing or whatever it does, it seems to boost performance. Do you know anything more about the techniques it uses and does GSAP do something similar? different? better? or are there some drawbacks to the process that FastDOM is using? etc. https://github.com/wilsonpage/fastdom
  23. Designing by screen size and available features is common practice, but what about hardware? I wanna do something like this: if (powerfulCPU) { // Use a crazy amount of blur } else { // Skip everything fancy but still deliver a killer animation } Is there a way to perform a quick CPU test in the loading sequence of a website in a similar manner that Modernizr does feature testing? Or do you have any other thoughts on how to achieve something similar?
  24. We are building a quite long storyboard which consists of about 12 scenes. Basically, you scroll down the page and things happen: SVG animations, curtain div's coming down and up, pinned screens etc. We have a LOT of TimelineMax functions and we are starting to experience some performance issues, most likely because all the animations are still running even when not on the screen. Is there a way to stop/start functions to optimise performance? If you guys have any advice / links, please let me know.
  25. Hi everyone! Would love to get your opinion on what might be causing performance bottlenecks in a page transition animation I'm working on. Live WIP site is here: http://adamwagner.io/ Click on the first image below the Lorem Ipsum "about me" section. The image is of a band playing. Notice the low frame rate as the image animates to the hero position, a circular splash element hides the page, and then the route changes to the project detail page. Click the "back" text at bottom left below the hero image. This will take you back to the home page with a reverse animation. NOTE: only works in Chrome because I'm using webm for the image I refer to above. Will fix for prod of course. Performance increases after multiple runs, but typically first run performance is very janky. I would love some tips - even if they involve a totally different approach. Thank you so much in advance! I've attempted to use best practices. For instance, I clone the image before animating, making it fixed position to avoid reflow. GSAP delightfully takes care of optimizing position tweens, but I also need to animate height and width. I also need to set autoRound: false, because I need perfect overlap with the real hero image once the transitory clone is removed. Here's the code: import React from 'react' import { injectGlobal, styled } from "styled-components"; import {TweenMax, Bezier, TimelineMax, Power3, Sine} from "gsap"; import store from 'store' // import ripple from '../utils/splash' let globalSpeed = 1; export default class ProjectImage extends React.Component { getDuration(start, end) { let pixelsPerSecond = 700; let duration = Math.abs((end - start) / pixelsPerSecond); // set min value of .2 duration = duration < .25 ? .25 : duration // set max value of .5 duration = duration > .5 ? .5 : duration return duration * globalSpeed; } onImageClick = (e) => { // get the first element - the <body> let body = document.body // get window width minus scrollbar let w = body.clientWidth let h = body.clientHeight // get clicked project element and position data let el_original = this.refs.project_image let {top, left, width, height} = el_original.getBoundingClientRect(); // clone it let el = el_original.cloneNode() // place element on top of original // find a cleaner way to copy these over let elStyles = ` cursor: pointer; width: 100%; height: 40vw; will-change: width, transform; background-image: url(${this.props.image}); background-position: center center; background-size: cover; pointer-events: none; ` el.style.cssText = elStyles + `z-index:200; position: fixed; top:${top}px; left:${left}px; width:${width}px; height:${height}px;` body.append(el) // get mouse click coordinates let {clientY, clientX} = e; // save original image coords for "going back" transition store.set('lastClickedProject', {top, left, width, height}) // create and append splash circle let splash = document.createElement('div') splash.style = ` border-radius:100%; width: 50px; height: 50px; background: ${this.props.pageColor}; position: fixed; top:${clientY}px; left:${clientX}px; z-index:100; opacity: 0.75; will-change: transform; ` body.append(splash) // animate splash TweenMax.to(splash, (0.6 * globalSpeed), {scale:80, opacity:1, transformOrigin: "50% 15%"}, Sine.easeIn); // animate image to the hero position TweenMax.to(el, this.getDuration(0, top), {bezier: {curviness:0.25, values:[ {x:0, y:0, width:width, height: height}, {x:-left, y:-(top/2.5), width: w, height: height+25}, {x:-left, y:-top, width: w, height: height+100}, ]}, ease:Power3.easeOut, autoRound:false}); // redirect to detail page setTimeout(() => { el.remove() splash.remove() window.___navigateTo(this.props.path) }, (this.getDuration(0,top)*1000)) } render() { let style = { cursor:'pointer', width:'100%', height:'40vw', willChange:'width, transform', backgroundImage:`url(${this.props.image})`, backgroundPosition:'center', backgroundSize:'cover', } return ( <div onClick={this.onImageClick} style={style} ref="project_image"> </div> ) } }
×