Jump to content


Jetpack-Dude: Sprite-Animation performance issue

Recommended Posts

CPU ca. 50% in Safari (9.1.3) and latest Chrome (58) on Mac OS X 10.11.6 El Capitan (fully blown up MacBook Pro Retina 15'' late 2013)


When I now add a yPercent-tween of a very tall scenery image to simulate jetpack-dude flying up, it starts lagging significantly and my fan prepares to take of to the moon.


Guessed reasons:

– My (probably highly improvable) Sprite-object

– stepped ease of a scaled up image with image-rendering: pixelated

– tweening xPercent instead of x

– sprite as <img/> instead of a background-solution

– src="data-uri.." (Nope, tried classic image reference, same issue)

– *.gif (Nope, *.png has same issue)

– force3D: false (Seems to be it?)


Comparing with other sprite-animations using GSAP I realized the probably familiar Santa Clause doesn't have this issue. CPU stays low.

I forked the pen and and changed it to also using force3D: false, xPercent and an <img />-solution. Still no CPU highening.


In my case removing force3D: false (it's default is true, right?) brought the CPU down (but not as low as the comparison).

But I need to preserve the pixelated look and therefore keep  .jetpack-dude sharp. 

Plus: Santa's CPU usage doesn't care about force3D




1) Why does force3D: false infects the CPU usage so drastically? (no GPU acceleration I assume?)

2) What can I do to keep the pixelated look with Santas performance?


See the Pen YVBMqe by katerlouis (@katerlouis) on CodePen


See the Pen GmzzBo by katerlouis (@katerlouis) on CodePen

Link to comment
Share on other sites


My guess is that it would be better to create the artwork at the size you need instead of scaling it up.

It appears your dude starts pretty small. 


See the Pen dWrjgp by GreenSock (@GreenSock) on CodePen


If you are going for a "big chunky pixels" look I'm doubtful you will notice any blurring of anything while the images are moving, especially in the erratic fashion you are going for with the jetpack


See the Pen WjmKVY by GreenSock (@GreenSock) on CodePen



  • Like 4
Link to comment
Share on other sites

Hello ..


I believe the issue is that you are using a base64 data:image uri. That type of image has very poor performance when animating, especially on mobile when the load event is fired on the image. Base64 images are good for mobile for static one time use images, but not for animating. You should try and replace your jetpack dude with an actual image gif, png, or jpeg. And you will see better performance.


GSAP default for force3D is "auto". And your element does indeed use no 3D transforms and is using matrix(), not matrix3d(). So force3D is not the problem, since it is doing what you asked, to be false.


See CSSPlugin Docs: https://greensock.com/docs/#/HTML5/GSAP/Plugins/CSSPlugin/

  • force3D
    As of 1.15.0, force3D defaults to "auto" mode which means transforms are automatically optimized for speed by using matrix3d() instead of matrix(), or translate3d() instead of translate(). This typically results in the browser putting that element onto its own compositor layer, making animation updates more efficient. In "auto" mode, GSAP will automatically switch back to 2D when the tween is done (if 3D isn't necessary) to free up more GPU memory. If you'd prefer to keep it in 3D mode, you can set force3D:true. Or, to stay in 2D mode whenever possible, set force3D:false. See http://css-tricks.com/myth-busting-css-animations-vs-javascript/ for more details about performance.


Happy Tweening :)

  • Like 4
Link to comment
Share on other sites

Thanks for the replies.

I fiddled around with an updated pen. Click to to toggle animation.


See the Pen oWVyom by katerlouis (@katerlouis) on CodePen


Why Base64?

The images are very tiny in size; so on poor internet the loading-bottleneck won't be the filesize, but the number of http-requests. In my early tests looking for the performance issue nothing changed when I went with referenced images. But I will test this again now.

(I figured once the base64 is encoded by the browser it behaves exactly the same as an referenced image-source)


As for the force3D:

When I leave force3D on auto (strictly speaking: just don't set any myself) the performance is way way better, but the everything gets really blurry.

a1) Why is it getting blurry, although auto chooses false under the hood, anyway?


Blurryness doesn't matter while moving:

I see what Carl means with the blurryness; it may not be an visual issue while the elements are moving, wiggling etc.

But as soon as they come to a stop, which the background and dude do, the images are blurry and look ugly as hell. The pixelated look feels like "tried hard, failed harder". Plus, because perceived image of the fire-sprite practially doesn't move at all, the blurryness is a pain in the butt here aswell.


Image scaling:

When I understand Carls suggestion correctly:

You would make the sprites and the background image larger, say stretch the look on a 1920 width image?

The background is currently  256*5.337px, 4 times larger would be 1.024*21.348px and even larger would be 1.920*40.027,5px.

The browser wouldn't need to scale that much,

a2) but wouldn't it be much harder for the browser to move ultra large images? 



Our *.gif's are by default more than 4 times smaller. So I naturally lean towards gif, although the sizes are in such low ranges, that it doesn't really matter.

I couldn't track a mentionable difference in performance, so far. Still I may be missing something here.

a3) Do you think there is a performance difference in moving PNG or GIF?



Totally new approach:

As long as the result is visually pleasing, I'm can deal with fan's starting to go nuts over a "simple website animation".

But on some devices I sometimes get noticeable frame-drops (very few actual lags/stutters)

I would be aboslutely okay with a low framerate. It actually suites the look we chose very well. But when you start with a smooth (60fps I guess?) experience you notice the difference once the framerate drops.


a4) Can I force GSAP / the browser / who ever to cap the animation at 30, 25 or 24 fps (Or maybe even lower)?


"requestAnimationFrame() to the rescue questionmark"

Link to comment
Share on other sites

Its not so much the initial loading of the base64 data URI and size of the base64 data URI image. But various browser bugs in rendering animated base64 images, that is why i recommended to just use a real image. :)

  • Like 2
Link to comment
Share on other sites

In the amount of time you've spent trying to optimize this, you could have learned canvas and been done with it. ;-)


The browser draws EVERYTHING on a canvas, like Skia. Yes, that includes SVG. I say skip all the formalities and just start with canvas to begin with. That's the path of least resistance.


Base64 is bad because it can block the browser from downloading the rest of the page. A texture atlas or sprite sheet is better.


For pixelation, CSS has this property, but with limited support.

image-rendering: pixelated;


Canvas has an imageSmoothingEnabled property with better support.

See the Pen 4594e9d126267200e6e8bc38407b64a3 by osublake (@osublake) on CodePen



  • Like 3
Link to comment
Share on other sites

Yeah, you are probably right; Canvas seems very interesting. 

But this project came in (like always, I guess?) pretty last-minutie. Never used canvas before, nor have I stumbled upon it more than 10 times in my path as a developer. For this project it would have been way too risky for me; But you are right– on the next project, maybe one where the animation part isn't the core-experience, I will dive into it :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.