MindGamer

I'm trying to think of a way this can be done with GSAP: I'm currently porting this site: http://ifate.com to HTML5/JS One of the Flash effects that's used throughout the site is the "gleam" or "phong" that you see rotating around the curved borders of content areas. You can see these 'gleams' moving around the main content area in the top left of the homepage. This used to be done pretty easily in Flash with masking, and rotating a gradient object behind the border mask. I've tried doing the same thing with CSS Masking and the result is very processor intensive, super janky and doesn't look great. So now I'm trying to approximate the same effect using DrawSVG which seems to be much faster/smoother. The problem is that I don't think I can achieve the necessary gradient effect using SVG gradients animated with DrawSVG. Here's my lame attempt to do it with multiple overlapping SVG paths.... Not great. The staggered colors are much too visible for me. https://codepen.io/Bangkokian/pen/QEZGkj Is there any way to apply a real gradient to a tweened SVG? The second issue that I noticed immediately, is that when you use DrawSVG on a circle or closed shape, there's a little jumpy weirdness around the point of origin. (In this case, at the top right of the box in the Codepen above). Is there any way to smooth out the transition from 100% around to 0% to 'rotate' the visible part of an SVG path around closed shapes? I tried animating the SVG from 0% 5% to 100% 105%, but that doesn't seem to work. Is there an approach to minimize this jump?

I'm trying to scale an ad down to the 150k filesize restriction that AdWords enforces, and I think my best bet is to move from TweenMax to TweenLite on a couple of creatives. I've actually never really used TweenLite as filesize hasn't been a major issue for me until now. Is there a concise feature-comparison chart showing what features I will need to pull from my TweenMax tweens in order to make them work with TweenLite? Thanks.

Not specifically a GSAP question... but relevant to all GSAP ads: I'm trying to figure out if it's customary to include CSS reset within HTM5 ad code. Obviously, it's important to control for style inheritance -- but is that something that's typically done at the creative level? Or is that something that's typically handled by an ad server? On a more macro level: Anyone know of a basic style guide for delivering HTML5 ad creative? (Facebook, Google, etc). Thanks

Seems like the issue is almost certainly the image size. Aside from forcing 3D, you could try animating a scaled, low-res image and then swap it for the high-res image onComplete. 'Might give the GPU a little more slack during the tween. 'Just a thought. Or use canvas instead.

Ah... must have been an old FP issue. I hadn't updated in forever. Updated to FP20 and it's all good. Thanks Carl.

I just noticed, one of our Flash games has a really awful jitter in all the GSAP tweens -- but only in Firefox. 'Looks 100% fine in Chrome and Safari. Anyone else seen anything like this? https://mindgamer.com/brain_training_paperboat_challenge/ (View in Firefox to see the issue).

Ah.. got it. Thanks Diaco & Jonathan for the wisdom! That was a huge help!

I did a quick hourglass spinner using an SVG graphic. It looks great in OSX Chrome and animates just fine. But the positioning seems to be off in Firefox & Safari. Is there a known issue with SVG positioning cross browser? Or possibly with transform-origin? Codepen is here: http://codepen.io/Bangkokian/pen/ZbZmmw (View in Chrome first to see the working version).

1. You can't embed .js in codepen the way you're doing it. Click the gear on the javascript panel. Then "QuickAdd" Greensock from the pull-down menu. You don't need any external js src calls. 2. Change your js to: TweenMax.to(".plane", 2, {x: 600}); ... and bob's your uncle.

...or you could always use onUpdate to pass a tweened value to a separate function where you can then update whatever property you want.

Using x/y instead of top/left will engage the GPU. This is better most of the time, but not every time. Engaging the CPU allows for smoother, subpixel rendering. And you'll experience fewer skips and jumps. But also since it uses subpixels it can result in a “blurrier” animation, since the image won't be defined perfectly on a per pixel basis. My typical approach is to use x/y when tweening something complex (especially something with CSS box shadows or blurs). And use top/left when tweening something simple with text that needs to stay crisp. Ketz -- if you can't get the performance to improve, you might want to try leaving off any box-shadows on tweened elements. That'll take a load off the processor.

You have two tweens happening simultaneously. You either need to use a timeline to start the second tween after the first one finishes... or use a delay of greater than 2 on your second tween.

Got a link to the non-working page?

retropunk -- as an alternative to using sprite sheets, you might want to consider saving your SVG data as javascript variables in an external js file. In a couple cases we've use an external .js which declares string variables containing SVG data. Those js files will cache. And just like spritesheets you can save on multiple http requests if you have multiple SVG's saved as strings in a single .js file.

Thanks for the response. Unfortunately though, splitting up the graphic into different paths would also change the animation visually. I've solved the problem just by setting the duration to much longer than it should be. But it looks like DrawSVG isn't accurately handling time when animating.

I've got a strange problem with DrawSVG animating an SVG graphic I made. The graphic seems to be animating at a speed much faster than the duration setting. TweenMax.fromTo(".flourishsvgclass",6, {drawSVG:0}, {drawSVG:"102%"}); This *should* take 6 seconds, but it's over in about 1. The only thing that I'm doing that's slightly different is that I'm declaring the SVG as a javascript variable. But I'm not sure why that would make any difference. You can see the issue in this Codepen: http://codepen.io/Bangkokian/pen/yNqVGr Any idea why it's ignoring the duration?

So if all the SVG images used with DrawSVG are inline, does that mean there's no way to cache the images used?

I'm using staggerTo to animate a class of elements in sequence. As in: TweenMax.staggerTo(".myClass", 1, {opacity:0}, 0.2); And that works fine -- except that it always animates the elements based on their sequence in the DOM. ie: The elements that are first-defined are first to animate. Is there a parameter to reverse that sequence? I feel like there should be an easy way to accomplish this without using a timeline -- but maybe not.

Was the .set just an example? Are you tweening in your actual use-case? If you're really trying to do it instantly, can't you just do something like (or vice versa depending on your order of operations) function scaleUp() { TweenMax.to('#a', 0, { scale: 2}); } TweenMax.to( '#a', 0, { y: '-50%', onComplete: scaleUp });

Impossible to say without knowing everything that's being done. But if it helps, we've had loads of problems with AdSense (and other ad network) ads loading on the page and causing extreme stutter / hiccups in Greensock animation just before the ads appear. There doesn't seem to be much way around it other than to delay the load of the ads using timeouts.

You might try using force3d even though you're not doing 3D transforms, just to offload some of the work to the GPU. I've had a couple of issues like this (with CPU-intensive scripts running in the background) and I've gotten around the issue just using setTimeouts and staggering the tasks -- or pre-calculating required computation .

In my experience the answer is also dependent on the size of the moving objects (in terms of screen real-estate) as well as the number of objects. I've done small particle systems animation with dozens of particles and had no problem whatsoever. But just a small number of large moving objects with a 3D transform can sometimes look jerky on a relatively good workstation. Test. Test. Test. It's the only way to know.

'Not a specific problem yet. Just trying to see my way through the project before jumping in. Mostly the .js version looks like it will be a very clean port as the Flash version is old AS2 (very close to .js), and the TweenMax syntax looks similar -- but the coordinate system on fluid display sizes is what I imagine the biggest difference is for most ports. No matrix transforms, so percentage coordinates should work just fine. Thanks for the reply.

I'm just beginning to get my head wrapped around a project which involves porting some of my Flash applications (built with TweenMax) over to javascript. I'm trying to understand what the best practice is for translating a fixed-coordinate system (Flash) to a flexible / multiple-resolution environment. (HTML). My Flash applications all run at full screen, so in order to simply account for all mobile environments, I assume that one simply creates a "screen sized" DIV set at height/width 100%. But since TweenMax uses a numerical coordinate system, I'm wondering if there's a commonly used approach to translate that to a percentage-based coordinate system? Can TweenMax work with percents instead of fixed coordinates? The examples I've found seem to use multiple CSS definitions for multiple platform types -- although this seems like a real pain -- particularly if the coordinates don't need to be that precise. Or is a % based method inadvisable for some reason?