Jump to content
GreenSock

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

Search the Community

Showing results for tags 'javascript'.

  • 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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Because you are one of the people who knew Flash and understood what made it great, I thought I'd ask. I was originally going to title this post "Any chance Greensock could replace CreateJS in AnimateCC?" Then I realized what I was asking was a little bigger. However, that is the gist of what I'm wondering. Is there a way to use the Greensock library as the engine that drives the animation when publishing from AnimateCC instead of CreateJS? The CreateJS library isn't getting updates (worse than Flash and Air). It's slow on mobile. Interaction is unbearably laggy. It's essentially unusable for any decent experience. But Greensock has always been the bleeding edge of speed, efficiency and stability. If it were powering all the timeline tweens and interactions when users published to html5, Flash could again be a viable tool for creating animation and games on the web. The Flash tool provided a wonderful GUI with which to create animation and games for coders and noncoders alike. When you published, it just worked. Nearly a decade after its 'death' we still haven't found a suitable replacement. Greensock is great. But there are those of us who find it prohibitively difficult to animate with code. And maybe I should just be asking for a Greensock GUI that has a timeline and MovieClips like Flash. But Animate is there. And it might just need the power and performance of Greensock to make it live again.
  2. Hi, I am trying to slide two lines in a campaign (one line in one frame and the second in the second frame). I want the second line to follow the first line after few seconds. I am able to slide in and slide out the first line but when I add the second line in the code, the code does not work. Can anyone help me out in this. Here is the link to the jsfiddle: https://jsfiddle.net/5pq750ko/ (If you remove line 4 and 5 from the JS code, you will see the code working. But when I will add the lines back, the code stops working) Thanks
  3. Hello, I have a websocket project I'm working on. When a user joins the site they get a div created for them with an icon as background image. I have a function that runs on DOMContentLoaded that creates fake user divs and wanted to build a timeline of animation moving them around via the X and Y properties in TweenLite. I am really stuck scratching my head - my TimelineMax produces console logs on Update() but nothinggggg moves. I could really appreciate a second pair of eyes! I've distilled the function in question down to a codepen. Thank you in advance! Stephen
  4. Sorry guys, my question might not be entirely related to Tweenmax or animations ( ) !! I stuck with the piece of code below where basically we animate sections with mousewheel . Each sections has it's own animations (intro and outro) .And i stuck at the end trying to concatenate functions and call them. I already ask on stackoverflow but their solutions is not something i'm confortable with yet. Here is the sample code var siteGlobal = (function(){ init(); var init = function(){ bindEvents(); } // then i got my function to bind events var bindEvents = function(){ $(document).on('mousewheel', mouseNav()); $(document).on('keyup', mouseNav()); } // then i got my function here for capture the event var mouseNav = function(){ // the code here will capture direction // nextSection(); } var nextSection = function(){ // Here we check if there is prev() or next() section // if there is do the change on the section // switchSection(); } var switchSection = function(nextsection){ // Get the current section and remove active class // get the next section - add active class // get the name of the section with data-name attribute // throw the animation var myFunctionOnEnter = window['section'+ Name + 'Exit']; } // Let's pretend one section is call Intro var sectionIntroExit = function(){ // animation code here } }(); Calling myFunctionOnEnter() doesn's seems to work..What did i do wrong?
  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. Club GreenSock members get a fresh batch of superpowers with updates to SplitText and ScrambleText, plus two brand new customizable eases in this 1st-Quarter 2017 update! It's our way of saying "thanks" to those who support our ongoing efforts. Let's dig right into the upgrades... SplitText SplitText now supports nested tags like <span>, <strong>, <em>, <p>, etc. This means you can split text with various styling and even links. To make things even cooler, SplitText now supports emoji characters ! SplitText demo See the Pen BzmGba by GreenSock (@GreenSock) on CodePen. "Simply Green" gets ScrambleText We moved ScrambleText into "Simply Green" membership level to deliver even more value. NEW: CustomWiggle and CustomBounce Add wiggle and bounce effects to your GSAP animations with these brand new, highly customizable eases. Even get squash and stretch! CustomWiggle and CustomBounce are now included for anyone with a "Shocking Green" or "Business Green" membership. To learn more visit greensock.com/wiggle-bounce. Thanks We're incredibly grateful to each and every Club GreenSock member, as we simply couldn't do what we do without your ongoing support. It's a privilege to have such a top-notch community around GSAP. Please feel free to plug in even more by participating in the forums to help others or to get your questions answered. It's a fantastic place to learn and be inspired. Enjoy the fresh updates, and happy tweening! [loginwidget]
  6. Hi guys! I am new to Greensock and I am so amazed about the power it has. I started to learn how to use it and during one of an example project I found a problem in which I can't go on. The problem: I have a panoramic photo, that is bigger than the screen and I want to use TweenMax to move over it and show also the hidden part, till now is everything ok, the problems come if I want to move to the same direction more than one time. For example when I want to discover the right part of the image and I push on my arrow button to move right the first time I push it works, but the second time I push it doesn't move again. Surely is a much more simple problem than how I think but I would really want to know if is normal that doesn't work more than once. Here there is the code of the Tweens: $('#frecciaDx').on('click', function () { TweenMax.fromTo("#stanza", 0.8, {css:{marginLeft:0}}, {css:{marginLeft:-200}}); }); $('#frecciaSx').on('click', function () { TweenMax.fromTo("#stanza", 0.8, {css:{marginLeft:0}}, {css:{marginLeft:200}}); }); $('#frecciaSu').on('click', function () { TweenMax.to("#stanza", 0.8, { y: 600 }); }); $('#frecciaGiu').on('click', function () { TweenMax.to("#stanza", 0.8, { y: -600 }); }); Thank you really much guys!
  7. 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. Have you ever tried getting a realistic wiggle effect or tweaking just how bouncy an ease is? What about adding squash and stretch to a bounce? These are not easy tasks. Well, until now. Even though CustomEase, lets you create literally any easing effect that you can imagine (bounces, wiggles, elastic effects, whatever) by drawing them, it's difficult to plot a complex wiggle or bounce while making sure all the points are spaced correctly. Wouldn't it be nice if you could just set a few parameters (like number of wiggles or bounciness) and have that complex easing curve created for you? Wish granted. CustomWiggle CustomWiggle extends CustomEase (think of it like a wrapper that creates a CustomEase under the hood based on the variables you pass in), allowing you to not only set the number of wiggles, but also the type of wiggle (there are 5 types; see demo below). Advanced users can even alter the plotting of the wiggle curves along either axis using amplitudeEase and timingEase special properties (see the docs for details). Demo: CustomWiggle Types See the Pen CustomWiggle Demo : resized by GreenSock (@GreenSock) on CodePen. Options wiggles (Integer) - number of oscillations back and forth. Default: 10 type (String) "easeOut" | "easeInOut" | "anticipate" | "uniform" | "random" - the type (or style) of wiggle (see demo above). Default: "easeOut" amplitudeEase (Ease) - provides advanced control over the shape of the amplitude (y-axis in the ease visualizer). You define an ease that controls the amplitude's progress from 1 toward 0 over the course of the tween. Defining an amplitudeEase (or timingEase) will override the "type" (think of the 5 "types" as convenient presets for amplitudeEase and timingEase combinations). See the example codepen to play around and visualize how it works. timingEase (Ease) - provides advanced control over how the waves are plotted over time (x-axis in the ease visualizer). Defining an timingEase (or amplitudeEase) will override the "type" (think of the 5 "types" as convenient presets for amplitudeEase and timingEase combinations). See the example codepen to play around and visualize how it works. How do you control the strength of the wiggle (or how far it goes)? Simply by setting the tween property values themselves. For example, a wiggle to rotation:30 would be stronger than rotation:10. Remember, an ease just controls the ratio of movement toward whatever value you supply for each property in your tween. Sample code //Create a wiggle with 6 oscillations (default type:"easeOut") CustomWiggle.create("myWiggle", {wiggles:6}); //now use it in an ease. "rotation" will wiggle to 30 and back just as much in the opposite direction, ending where it began. TweenMax.to(".class", 2, {rotation:30, ease:"myWiggle"}); //Create a 10-wiggle anticipation ease: CustomWiggle.create("funWiggle", {wiggles:10, type:"anticipate"}); TweenMax.to(".class", 2, {rotation:30, ease:"funWiggle"}); Wiggling isn't just for "rotation"; you can use it for any property. For example, you could create a swarm effect by using just 2 randomized wiggle tweens on "x" and "y", as demonstrated here. CustomBounce GSAP always had the tried-and-true Bounce.easeOut, but there was no way to customize how "bouncy" it was, nor could you get a synchronized squash and stretch effect during the bounce because: The "bounce" ease needs to stick to the ground momentarily at the point of the bounce while the squashing occurs. Bounce.easeOut offers no such customization. There was no way to create the corresponding [synchronized] scaleX/scaleY ease for the squashing/stretching. CustomEase solves this now, but it'd still be very difficult to manually draw that ease with all the points lined up in the right spots to match up with the bounces. With CustomBounce, you can set a few parameters and it'll create BOTH CustomEases for you (one for the bounce, and one [optionally] for the squash/stretch). Again, think of CustomBounce like a wrapper that creates a CustomEase under the hood based on the variables you pass in. Options strength (Number) - a number between 0 and 1 that determines how "bouncy" the ease is, so 0.9 will have a lot more bounces than 0.3. Default: 0.7 endAtStart (Boolean) - if true, the ease will end back where it started, allowing you to get an effect like an object sitting on the ground, leaping into the air, and bouncing back down to a stop. Default: false squash (Number) - controls how long the squash should last (the gap between bounces, when it appears "stuck"). Typically 2 is a good number, but 4 (as an example) would make the squash longer in relation to the rest of the ease. Default: 0 squashID (String) - the ID that should be assigned to the squash ease. The default is whatever the ID of the bounce is plus "-squash" appended to the end. For example, CustomBounce.create("hop", {strength:0.6, squash:2}) would default to a squash ease ID of "hop-squash". How do you get the bounce and the squash/stretch to work together? You'd use two tweens; one for the position ("y"), and the other for the scaleX/scaleY, with both running at the same time: //Create a custom bounce ease: CustomBounce.create("myBounce", {strength:0.6, squash:3, squashID:"myBounce-squash"}); //do the bounce by affecting the "y" property. TweenMax.from(".class", 2, {y:-200, ease:"myBounce"}); //and do the squash/stretch at the same time: TweenMax.to(".class", 2, {scaleX:140, scaleY:60, ease:"myBounce-squash", transformOrigin:"center bottom"}); See the Pen CustomBounce from GreenSock by GreenSock (@GreenSock) on CodePen. Where can I get it? CustomWiggle and CustomBounce are membership benefits of Club GreenSock ("Shockingly Green" and "Business Green" levels). It's our way of saying "thanks" to those who support GreenSock's ongoing efforts. Joining Club GreenSock gets you a bunch of other bonus plugins and tools like MorphSVGPlugin as well, so check out greensock.com/club/ for details and sign up today.
  8. GreenSock

    CustomEase

    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. Are your animations meant to feel playful? Robotic? Slick? Realistic? If they had a voice, what would they sound like? To become an animation rock star, you must develop a keen sense of easing because that's what determines the style of movement between point A and point B. GreenSock's new CustomEase frees you from the limitations of canned easing options. Create literally any ease imaginable. Zero limitations. CSS animations and WAAPI offer cubic-bezier() which is great but with only two control points it's impossible to create more complex effects like bouncing, elastic, wiggles, rough/jerky eases, etc. Plus you can't make an ease return to its starting values (like a ball jumping into the air and falling back to the ground with a bounce). Features Unlimited anchors and control points. Copy/Paste any SVG <path> (including directly from Adobe Illustrator). Use CSS cubic-bezier() values (For example, from cubic-bezier.com). Editor has snapping, undo, sample code and other conveniences. Start with any standard ease and customize it. getSVGData() method turns any ease into SVG <path> data for display at the size you define. Extremely optimized for runtime performance. Free for anyone with a GreenSock account. Reading Ease Curves, Editing, and Using CustomEase Here's an in-depth video tour that'll get you up to speed with exactly how to use CustomEase: Ready to play? Check out the new Ease Visualizer with CustomEase support. Edit the curve as much as you want: Download CustomEase Get CustomEase by creating a FREE GreenSock account which gets you access to our community forums plus you’ll receive our exclusive “GreenSock Insider” email series (you can unsubscribe anytime). Use the widget below to sign up (or if you’re already logged in, you’ll get immediate access to the download zip containing CustomEase). Note: CustomEase is not in the github repository or CDN; it's only available for download at GreenSock.com. [loginwidget]
  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. Are your animations meant to feel playful? Robotic? Slick? Realistic? If they had a voice, what would they sound like? To become an animation rock star, you must develop a keen sense of easing because that's what determines the style of movement between point A and point B. GreenSock's new CustomEase frees you from the limitations of canned easing options. Create literally any ease imaginable. Zero limitations. CSS animations and WAAPI offer cubic-bezier() which is great but with only two control points it's impossible to create more complex effects like bouncing, elastic, wiggles, rough/jerky eases, etc. Plus you can't make an ease return to its starting values (like a ball jumping into the air and falling back to the ground with a bounce). Features Unlimited anchors and control points. Copy/Paste any SVG <path> (including direct copy/paste from Adobe Illustrator). Use CSS cubic-bezier() values (For example, from cubic-bezier.com). Editor has snapping, undo, sample code and other conveniences. Start with any standard ease and customize it. getSVGData() method turns any ease into SVG <path> data for display at the size you define. Extremely optimized for runtime performance. Free for anyone with a GreenSock account. Reading Ease Curves, Editing, and Using CustomEase Here's an in-depth video tour that'll get you up to speed with exactly how to use CustomEase: Ready to play? Check out the new Ease Visualizer with CustomEase support. Click "Custom" to edit the curve as much as you want: Simple Example See the Pen Video: Single Tween with CustomEase by GreenSock (@GreenSock) on CodePen.&#13;We strongly recommend creating your CustomEases initially (rather than in each tween) to maximize performance and readability. You then reference them by ID in your tweening code. When an ease is created, it must parse through the points and do various calculations to prepare for blisteringly fast runtime performance during the animation, so executing those calculations when your page/app loads is typically best. Download CustomEase To get CustomEase, you must have a GreenSock account which is completely free to set up. Plus it gets you access to our community forums (a fantastic place to learn and get your questions answered). The widget below lets you sign up or if you're already logged in, it'll give you immediate access to the download zip that contains CustomEase in the "easing" directory. Note: CustomEase is not in the github repository or CDN; it's only available for download at GreenSock.com. [loginwidget]
  10. Hey guys I am Justin, first post here. The community over here seems to know there stuff so hopefully you can solve my problem with making tabs in GSAP I am making this website like eBay, but much smaller scale. The top of the site is broken into three tabs. Browse / My Hub / Sell. If the user is in the browse tab he will be searching listings (this is also the default tab on the home page) If the user is in My Hub he will be looking at account information and watchlist... If the user is in sell he will be selling things ect. I can do simple tabs no worries but I need help with advanced tabs. Each tab will have lots of links and links within links ect. But I want the tabs to act just like the tabs do in chrome, so the user can go to all different places in each tabbed section of the site and the other tabs will be right how they were... This is so users can be browsing and decide to add funds, sell something, look at there account, update details.... they can then go back to where they were browsing. Maybe I can use browser cache for the other two tabs that are not used each time the used tab page loads. I would almost want it so the user could upload photos in the sell tab wile browsing listings in the sell tab. I don't know if it can be done, but I am looking forward to any advice/basic codepen.
  11. I just finished creating 2 minutes animation with ~80 objects. I spend more time then i would we spend in after effects or photoshop, but i can make edits 10 times faster, then in Adobe programs. I already asked about UI and got an answer that Greensock using tweenui.com behind the scene (or vise versa). (I can't use this tool, because it's same "Adobe layers timeline system" that i am trying to get rid of using greensock.) One of the most time consuming thing was in the end - adding new object to my scene. 1. I create div element with a path to image source and id 2. I create var shortcut image_name = $("#image_name") (just realized this is not necessarry) 3. I set object to opacity:0 and showing it when it's time My question is - what technologies i can use to make this step easier? I think i should create json array and parser for it. And add image to json dynamicly. And create new array for this image that will have greensock .set function ... okay, my brain just pooped at that point. Can you give me a hint of what should i use? Thank you forum.
  12. im try to fire timeline when a li it's hover, so i create a var with my timeline, and with event.delegateTarget to find children and not all with .CLASS this is my code $(".gb-help-list ").on('mouseover', 'li', function (e) { console.log('mouse'); var tl = new TimelineLite(); tl.to($(event.delegateTarget).find('.line-help'), 2, {width: '100px', ease: Power4.easeOut}) .to(".line-help", 2, {width: '100%', ease: Power4.easeOut}, "-=1"); }).on('mouseout', 'img', function (e) { TweenLite.to($(e.delegateTarget).find('span'), 1.5, {opacity:0}); }); I don't see any error in console, but this : o($(event.delegateTarget).find('.line-help'), 2, {width: '100px', ease: Power4.easeOut} doesn't fire.... anyone can helpme? Thx in advance
  13. Hi - this isn't a strictly GSAP related question, but you guys are wicked smaaaht, so I thought I'd ask here. (Incidentally, I'm using the fantastic Bannertime generator from @joe_midi, but this isn't related to that either). I have a object that's centered in the browser window using a combination of negative margins and absolute positioning. When resizing the browser window, the border flickers on the right and bottom edges in Safari only - it's fine in Chrome and Firefox. The structure of the object is as follows: <div class="banner"> <div class="border"></div> </div> The .border div is 2px smaller than its parent element, to account for the 1px border all around, and it's this border that flickers when the browser is resized. I have a demo of this in action here. Again, I see this behavior in Safari only. I would love any suggestions as to how I can prevent this from happening. Thanks, guys!
  14. I'm using the Greenscok Draggable as a themostat. The temperature increases or decrease at every 18 degrees rotation (also based on clockwise or counter-clockwise). I'm grabbing the rotation and using the remainder operator (%) and if it is equal to 0, the temperature changes. With the dial at 0 (rotation), the temperature is at 18 and at -180 (rotation), the dial should reach 26 degrees. However, the rotation and the temperature don't seem to be working in unison. Just to add, the temperature should be at 22 degrees at -90 (rotation). Here is the codepen: http://codepen.io/jetchy/pen/EgAdgP Thanks.
  15. Hello, I'm uploading my published Adobe Animate creative to Google Adwords, I've never done this before. I have in my zip file the image, the javascript, and the HTML so everything should be good to go. However when I upload and preview it, it doesn't animate. It's just the static background image. Am I doing something incorrectly with my code? Should I be doing something different with my publishing settings in Animate? Has anyone else encountered this when trying to put an animated ad onto Adwords? Thanks in advance for your help.
  16. 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. Chrome 53 debuted a new "feature" to improve animation performance and graphics fidelity, but it had some nasty side effects that caused quite a few animators to get unpleasant phone calls from angry clients whose ads and web sites suddenly looked blurry and/or stuttery. Every other browser (including previous versions of Chrome) render the same animation beautifully. Chrome's new behavior may also result in WORSE animation performance. A lengthy discussion with the Chrome team revealed some disturbing tradeoffs that animators need to know about, and that could spell trouble with other browsers too unless we band together as a community and make our voices heard. At the heart of the controversy is the will-change CSS property. What is "will-change"? It gives developers a way to say "hey, browser, I'm gonna animate this property, so please do whatever you can to prepare and make it happen smoothly" which often means creating a compositor layer to get GPU-acceleration of transforms and opacity. Think of a compositor layer like a screen-shot of the element that the browser can store on the GPU to move/scale/rotate cheaply instead of re-computing all the pixels on each screen refresh. Read Sara Soueidan's excellent in-depth article here for details. Problem: blurry, stuttering animations What is Chrome 53 doing differently? Chrome is basically saying "In the past, I intelligently managed when and how to rasterize elements, but now that will-change property exists, I'll just make that serve as a blind toggle switch for rasterization instead. If things look blurry, it's not my problem - the developer will need to jump through some hoops (described below) to make things look sharp again." It all boils down to how and when "rasterization" of an element occurs (changing it into pixels stored on the GPU). If rasterization happens when the element is very small, it will be lower resolution. When scaled up, it'll look blurry/pixelated. On the other hand, if you rasterize while it's at its native scale (1) or above, you'll get a much higher-quality image with more pixels. Another key factor is how it is rasterized. Apparently Chrome uses a completely different algorithm for rasterizing an <img> than a <div> with a background-image even though both use identical source files and are sized the same! Here's an example of how they look in Chrome 53: Update: The Chrome team says they've fixed the bug that caused background-image to render differently than <img> (issue 649046) and it should be in the 9/29 release of Chrome Canary. Both factors (the when and the how) are at play in Chrome 53's new behavior (which apparently was a purposeful engineering choice based on will-change). According to this document, all content now gets re-rasterized when its scale changes (which happens up to 60 times per second during animation of scale/scaleX/scaleY properties). That's supposed to keep things sharp, but in this case Chrome's background-image algorithm applies some sort of pixel-snapping which causes that odd vibration during animation. (Update: should be fixed soon). This re-rasterization comes at a cost performance-wise too. Previously, Chrome applied some heuristics to sense when it was appropriate to re-rasterize to avoid blurriness, thus it only kicked in when necessary. But now, you must opt-in to get the layerizing benefits by setting will-change: transform. The Chrome team says this is an "improvement" because it puts the control into the hands of developers, but clearly this shift in behavior comes at quite a price. Overnight, the rug got pulled out from under many animations around the web, hurting performance (due to the constant re-rasterizing by default) and also introducing those visual vibrations when scaling background-image graphics (quite common for sprite sheets). To be clear, this primarily affected scaling animations, not ALL animations on the web. And of course anything where a background-image was used and the element was layerized (making it blurry in Chrome 53). Partial solution: set will-change: transform Complaints rolled in quickly, and the Chrome team suggested that developers go back and edit all their affected animations by adding will-change: transform which would layerize/rasterize those elements (skipping re-rasterizing on every refresh). It's a bit of a nightmare to go back and find all the affected animations and make the necessary edits, but hey, it's just adding one property to the CSS so it shouldn't be too bad, right? Oops, that breaks it in other ways Chrome chose to implement will-change such that it will trigger rasterization at whatever the current scale happens to be, so if you've got an element that starts at scale(0.1) and animates up to scale(1), rasterization happens at scale(0.1), thus it will look terrible (blurry/pixelated) at the end of the animation. Here's an example showing the SAME image animating to identical scales, but flip-flopped starting/ending values: (View the codepen here) Partial solution: toggle will-change back and forth Hold your nose...here comes the hack. In order to trigger re-rasterization of the element to keep it clear, the Chrome team suggested toggling will-change back to auto during the animation, then waiting until a requestAnimationFrame elapses before setting it back to transform...and then doing it again, and again, at whatever frequency the developer wants in order to keep things acceptably sharp. So will-change: auto is being pressed into service to explicitly tell the browser "rasterize me on the next requestAnimationFrame." Yes, you read that correctly: animators must turn **off** the very property whose entire purpose is to be **on** for animation, signaling change. Then toggle it back-and-forth many times during the animation. So we're essentially telling the browser "I'm gonna change this...no I'm not...yes I am...nope..." all while in the process of animating. This doesn't exactly sound consistent with the intent of will-change, nor does it seem performant (Google's document says "Be aware, however, that there is often a large one-time performance cost to adding or removing will-change: transform.") Gotcha: never de-layerize Even if you're willing to follow the advice to set will-change: transform and toggle back-and-forth during the animation to maintain a reasonable level of clarity, there's one last gotcha - if you set it back to will-change: auto at the end of the animation and give it a non-3d transform (to de-layerize it), you'll see a jarring shift in pixels and clarity for anything with a background-image! The Chrome team advises in that case that you make sure it always has a 3d transform thereafter to prevent it from de-layerizing. Following that advice puts you at risk of running out of memory (or hitting performance problems), plus the background-image will always be slightly blurry. Here's what it looks like to toggle between the two modes at the end of the animation: Update: The Chrome team clarified that this was a temporary fix, not a long-term solution. The background-image rendering bug should be resolved soon, and this "never de-layerize" suggestion will no longer apply at that point. The bigger issue, beyond Chrome... The will-change spec doesn't really specify implementation details which means that Chrome's new behavior may be completely unique; Firefox might do something different, and then there's Edge, Safari, Opera, Android, etc. Perhaps Chrome requires that developers toggle back-and-forth to maintain clarity, but what if Firefox interprets that differently, or imposes a big performance penalty when doing the same thing? What if developers must resort to various [potentially conflicting] hacks for each browser, bloating their code and causing all sorts of headaches. We may have to resort to user agent sniffing again (did you just throw up a little in your mouth?). This will-change property that was intended to SOLVE problems for animators may end up doing the opposite. It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward. Another problem: stacking contexts As mentioned in this article, will-change can also affect the stacking context of elements, leading to unintended changes in how things render/stack on your page. So your content may stack differently in browsers that do support will-change than those that don't. More sniffing, yay! To summarize: Before Chrome 53 Just animate stuff. No need to jump through any hoops as a developer to get decent clarity (though the Chrome team points out that there was still some blurriness in certain edge cases that they've heard complaints about). After Chrome 53 Make sure to set will-change: transform if you're animating transforms and want to opt-in to performance optimizations and avoid jittery background-image scaling. But be careful about how it might affect stacking contexts, and keep checking when other browsers decide to implement will-change, as it could change how your content looks. If you're scaling up, make sure you toggle will-change back-and-forth to/from auto during the animation to maintain clarity (but sacrifice performance). Make sure there's a 3D transform applied throughout to prevent de-layerization (which would cause a big performance hit). Don't switch back to a 2D transform at the end (at least for elements with a background-image), or you'll see a jarring pixel shift. (Update: should be fixed soon in Chrome, so this step won't be necessary at some point.) Don't forget to go back and find/fix existing animations that are affected by the new Chrome behavior. Is Chrome going to fix this? As of today, the Chrome team says they've thought a lot about this and feel pretty strongly that the new behavior is an improvement, so there's no plan to change it (that we know of at least). Here are the solutions we proposed (with the answers we got): Instead of putting the burden on developers to manually toggle will-change back-and-forth between transform and auto during the animation, just have the browser natively sense when re-rasterization is prudent and do that automatically which would be much faster than JS anyway. It seems rather trivial for the browser to sense when an element has been scaled greater than a certain delta (like 0.2) and trigger a rasterization. Chrome team's answer (summary): "that's too hard (complex). The browser might get it wrong sometimes, so it's better to have developers do it at the JS level. And JS isn't that much slower than native. It's just a small amount of extra work for animators (or library developers)." The browser could always perform rasterization at native size (scale of 1) or the current scale, whichever is bigger. That way, nobody would run into those nasty blurred images when scaling up from a small value to 1 (pretty common) and there's no need to keep re-rasterizing. Chrome team's answer: "rastering at native size and then scaling that down with bilinear filters in the compositor to something less than 0.5 or so will start to loop noticeably bad." If the goal is to put control into developers' hands, why not expose an API for defining what scale rasterization should occur at, like element.cacheTransform = "scale(1)"? Chrome team's answer: "it may not be so easy to get it right in terms of expressiveness, and requires new APIs...and also to define what raster scale means, which seems quite tricky in general, especially while not over-fitting to current implementation strategies. That might happen later on." The browser should use the same algorithm to rasterize (and scale) anything. The one being used by Chrome for <img> looks great so please use that for background-image too Chrome team's answer (summary): "Acknowledged. We're working on a fix." Instead of turning will-change into a convoluted way to control rasterization in the browser and risk opening a can of worms with other browsers doing things completely differently due to vague specs, roll back the behavior and work with the spec authors to define implementation details and re-approach later when consensus is reached. Chrome team's answer: "the intention of will-change is to give a hint to the browser that the referenced property is going to be animated, and for the browser to take steps to optimize performance for that use case. This is why will-change: transform creates a composited layer: because animating transform afterward will therefore not later have the startup cost and per-frame of creating the composited layer and rasterizing it. Following this logic, further extending the meaning of will-change: transform to not re-raster on scale change is similar, because it will make it faster." Can GSAP fix it for me? Yes and no. We've already experimented with the suggestions that the Chrome team made, but there are a few tricky challenges. First, we're hyper-focused on performance so it's quite painful to have this new Chrome behavior force us to add extra logic that must run on every tick of every tween of any transform-related animation. It probably wouldn't be noticeable unless you're animating hundreds or thousands of elements simultaneously, but we built GSAP to handle crazy amounts of stress because sometimes that's what a project requires, so we're pretty frustrated by Chrome's decision to impose this burden on animators and libraries like GSAP. But yes, we could do the toggling under the hood automatically and accept the performance tradeoff. But another major problem that's totally in the hands of browsers is rendering - we can't fix that jarring pixel shift at the end of the animations of background-image. We can force the 3D transform to remain, but as described above, that leaves things blurry and unnecessarily eats up memory. We work very hard to implement workarounds for browser inconsistencies and bugs like this, but we can't work miracles. We really need Chrome to step up and provide some better solutions. Conclusion There's no doubt that the Chrome team is working hard to move the web forward and deliver the best experience for their users. At GreenSock, Chrome is our primary browser that we use every day, so we're big fans. This article isn't intended to criticize anyone, but rather to bring attention to something that could spell big trouble for animators in the days ahead, beyond the headaches Chrome 53 caused with its new behavior. Hopefully Chrome will roll back the changes and/or implement some of the suggestions above. We'd encourage folks to make their voices heard (on the Chrome thread, below in the comments, with the spec authors, etc.). Perhaps we got something wrong - feel free to correct us or make other suggestions. Ultimately we want to help move animation forward on the web, so please join us.
  17. Hey guys please please help to understand THIS on javascript. I am trying to use THIS to select the same selector from parent function. Here's example: function Animate() { console.log("Clicked!"); TweenMax.to("#thing", 1, {onStart: a}); } function a() { console.log("Yeah!"); TweenMax.to(this, 1, {y: "100px"}); } I know this is clever but I want to know how to select the same selector from parent function. Same as THIS.
  18. Hi Guys, I've been lurking on this forum for a while and have hit finally got to the point where I need to ask some questions. Firstly I'd like to say Hi and I really like what I've seen on this forum, I've been a full stack developer for 16 years but the banner world is fairly new to me (I did help out with some flash banners way back). The situation I'm in is I'm a tech lead, the previous front end dev used to look after the banners and the process was very adhoc. I have a freelancer with no banner experience so I'm trying to hold his hand through the process even though I don't know much more than him. I'm trying to put some processes and standards in place for banner development. For the campaign that I'm working on currently, I've tried out this Yeoman generator - BuildABanner , using the DoubleClick template. I like what I see, it's generating a nice folder structure, with nice gulp tasks and best practices (polite loading content etc). Using the DoubleClick template it makes proper use of the enabler events and it's triggering an Exit event as the clicktag. I can see in the console when I click on it that the enabler is receiving the event. Example; bgExit = document.getElementById('background_exit_ad'); //Add Event Listeners for DoubleClick addListeners = function() { bgExit.addEventListener('click', bgExitHandler, false); } bgExitHandler = function(e) { //Call Exits Enabler.exit('HTML5_Background_Clickthrough'); } I've been tasked with developing some banners built to 'doubleclick' spec but will be served on two different networks/suppliers (Cadreon and Ansible). I'm still struggling to grasp the difference between the platforms and networks etc. So I thought I'd do a test before sending it off to the media agency (so I don't look like an idiot). I tried out this DoubleClick Campaign Manager HTML5 Validator. When I validate my banner (with the above click tag) it passes all the rules except for the click tag and says that it's not present. I thought that the enabler.exit event was the best practice way to do this? When I look back at some previous banners developed by my old front end dev, he had simply referenced the enabler.js, but implemented the click tag this way, marked up in the comments as "Standard ClickTag"; Example; <html> <head> <meta name="ad.size" content="height=0,width=0"> <script src="https://s0.2mdn.net/ads/studio/Enabler.js"></script> <script> var clickTag = "http://www.google.org"; </script> </head> <body> <a href="javascript:window.open(window.clickTag)">blah</a> </body> </html> Adding this into my banner along side the exit event would be doubling up the events so as I see it - I should be using one or the other? Is this tool just stupid? I don't mind simplifying the code and doing it the generic way but it makes more sense to me as a dev to use the proper events within enabler and it would also allow me to keep the buildabanner generated code as untouched as possible. Also does anyone have any feedback on the buildabanner system itself?? Does anyone use it? Or do you use a different yeoman tool? Very keen to hear some real world feedback on this. Thanks Marty
  19. Hi guys, I have these timelines that's very similar and I'm wondering if it's possible to loop through them or something to have a cleaner code? This is what I'm working with: var rt_step1 = $('.contact_module2016 .step1'), rt_step2 = $('.contact_module2016 .step2'), rt_step3 = $('.contact_module2016 .step3'), rt_step4 = $('.contact_module2016 .step4'), rt_step5 = $('.contact_module2016 .step5'), step1Timeline = new TimelineMax(), step2Timeline = new TimelineMax(), step3Timeline = new TimelineMax(), step4Timeline = new TimelineMax(), numbers = ["step1Timeline", "step2Timeline", "step3Timeline", "step4Timeline"]; step1Timeline.to(rt_step1, 0.6, {autoAlpha: 0, display:'none', ease: Expo.easeInOut, y:-30}) .to(rt_step2, 0.6, {autoAlpha: 1, display:'block', ease: Expo.easeInOut, y:0}); step1Timeline.pause(); step2Timeline.to(rt_step2, 0.6, {autoAlpha: 0, display:'none', ease: Expo.easeInOut, y:-30}) .to(rt_step3, 0.6, {autoAlpha: 1, display:'block', ease: Expo.easeInOut, y:0}); step2Timeline.pause(); step3Timeline.to(rt_step3, 0.6, {autoAlpha: 0, display:'none', ease: Expo.easeInOut, y:-30}) .to(rt_step4, 0.6, {autoAlpha: 1, display:'block', ease: Expo.easeInOut, y:0}); step3Timeline.pause(); step4Timeline.to(rt_step4, 0.6, {autoAlpha: 0, display:'none', ease: Expo.easeInOut, y:-30}) .to(rt_step5, 0.6, {autoAlpha: 1, display:'block', ease: Expo.easeInOut, y:0}); step4Timeline.pause(); This is what I'm trying to do but I get the error that numbers is not a function. Anyone done this before? for (i = 0; i < numbers.length; i++) { numbers[i].to(rt_step1, 0.6, {autoAlpha: 0, display:'none', ease: Expo.easeInOut, y:-30}) .to(rt_step2, 0.6, {autoAlpha: 1, display:'block', ease: Expo.easeInOut, y:0}); numbers[i].pause(); } Thanks so much for your attention and all the help
  20. HI! I want to convert timeline lite elements with their animations into canvas animation, I mean the whole dom element and its children that contains timeline lite animations. an animation like this one http://codepen.io/ihatetomatoes/pen/QboVVV is there way to do that? I've found some libraries that only take a screen shot of the page but no animations.
  21. Dear All, i have seen this tutorial where the animation can be controled by the input value of a slider. http://greensock.com/sequence-video I have a variable definde in my code which has a value between 0 and 1. Is it possible to control the progress for the animation with the value from this variable?
  22. First of all, you can find a simplified demo of my code in this JSFiddle. I found that my problem happens the way I describe it in Google Chrome, so if you plan to try and fix the bug, please use that browser. I apologize if the code is not very well simplified; please consider that this is a snippet from a bigger project. I'm working on a webapp that uses JQuery and GreenSock's TweenLite for animations. This app consists on some menus that control everything, that are transitioned between using the bodyChange() function. This function has two parameters: nextOrPrev, that runs one animation or another based on the value provided ("next" or "prev"). Only the "next" animation is done yet, but that is not important for now. The "prev"animation, not yet used, just emits an alert("prev"). bodyFunction. The function provided will fill the body with the elements necessary for that menu, and the wrap them in a #bodyWrap. In the demo I provide you with there are only two menus: The first one, mainMenu, with only a #playButton. When you click it, the bodyChange() function is called with the following parameters: ("next", playSettingsBody), playSettings being the second menu. This is the problem: when you click the playButton, the button goes up a on the screen and then executes the TweenLite animation. I can't see, however, why does the button "jump up", instead of staying in the same place and execute the animation. This is probably due to a small mistake. What is it? Thanks for any help.
  23. GreenSock

    GSAP 1.19.0 Released

    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. GSAP version 1.19.0 introduces some exciting new features for advanced users as well as conveniences for everyone (even the "greenest" novices). The most noteworthy improvements are summarized below: Function-based values Instead of a number (x:100) or string (width:"300px") or relative value (y:"+=50"), you can now define most values as a function that'll get called once for each target the first time the tween renders, and whatever is returned by that function will be used as the value. This can be very useful for randomizing things or applying conditional logic. See it in action in the demos below. See the Pen BzmGba by GreenSock (@GreenSock) on CodePen. ...and more GSAP 1.19.0 is more ES6-friendly (for example, you can npm install gsap and then import {TweenLite, Elastic, TimelineMax} from "gsap" in your project). Plenty of bug fixes too. See the whole list in the github changelog. DOWNLOAD GSAP TODAY Happy tweening!
  24. I know this is a bit off topic but i wanted to know is there anyway to do this? I'm creating a animation editor and i used GSAP for tweens and timeline,and I want users to be able to export animation as video and download them.
  25. Can you use GSAP's timeline to execute a javascript function @ certain time?
×