Troubleshooting stutter in animation

I have a series of banner ads in various sizes that work great, except for the one that I have sized at 1200x1200px. (Unsure what this unconventional size is for, but it's a client request.) I've eliminated the unnecessary elements in this attached version. The logo movement stutters right when the lines of text (images) begin to change opacity from 0 to 100.

This happens in all browsers I've tested, but does not happen when exported as a movie. Do you think this problem is some kind of browser limitation? Or something with my computer processing? The standard size banners work fine. I'm not sure what to make of it.
1200x1200 (84.5 KB)

MacOS 10.14.6

When animating the opacity setting of just the "Scene Final" Folder was used (your original set-up)...
No stuttering: Safari 14.0
Stuttering: Firefox 91.0.1, Chrome 93.0.4577.63

No stuttering for any of the above browsers when the individual text (image) elements in the group (folder) had their opacity animated but the "Scene Final" folder itself had the animation removed.

Also stuttered for me, I fixed it by removing the fade-in opacity animation on your group, and re-applying it.

Same results here, just forgot to include Safari :laughing:

Either of the animated elements are fine when they run on their own. It's when the 2 are combined, that the fade-in of element #2 makes element #1 skip a beat. I'm running essentially the same versions of everything that you are.

Thanks for taking the time to take a look!

I just tried the same thing you describe (to both to my uploaded test file and my original) and it doesn't fix the problem for me. :slightly_frowning_face:

Thanks for looking into it! I'm gonna keep troubleshooting.

reapplying animations did not fix it to me either ...

Chrome's performance tools are the best way to look into issues like this. If you record and reload the page, you'll be able to gather all kinds of information on what the browser is doing that may provide vital clues. Here's a run:

In the Frames section, the red box indicates the dropped frame, so you can look just before that to see what is happening. The most concentrated section appears to be 4 different "Raster Threads".

Rastering is the process of converting image information into bitmap image data. Sure enough, you have 4 images that fade in as part of the animation. Thus the Raster process is waiting until the images are shown to change the .png image data into a bitmap representation to display on the screen.

All four of these images are only 75 KB total, so that seems small. But the reality is they are just highly optimized since they contain tons of alpha information. Each being 2,400 x 2,400 pixels in size, when rasterized they occupy 22 MB each of bitmap image data, or 88 MB total. This allocation and drawing takes a while (well, 25 milliseconds on my machine which is longer than a frame draw).

Chrome trying to be clever by deferring the rasterization until the image is first shown. Since with dynamic content the image may never be shown, it is able to potentially save memory, at the expense of doing this work later and perhaps causing a stutter. Safari takes a different tradeoff, and tends to rasterize when the image is in the DOM, regardless of opacity.

You could probably try tricking Chrome to rasterizing earlier by doing something like starting it at 1% opacity where it is imperceptible to humans, or covering up the background, but this is probably a bit silly.

Instead my recommendation would be to crop the images to their content so they are much smaller. They are nearly all blank space and don't need to be 2400x2400. This will be kinder on everyone's machines too, since you won't be eating up their RAM.

Otherwise you could also use text, though you'd need to use a webfont to display it all properly. This also has added benefits of accessibility. I get why images in this case may be easier since you've already got the assets though.


Nice sleuthing!

1 Like

When I reapplied the fade, I see I timed it different resulting in the fade to be done just before the image slides in, which initially fixed it for me.

If image sizes are are OP’s problem as Jonathan found out, another suggestion for him instead of using a webfont would be to turn his text into a svg vector file. This keeps the file sizes down and always make the copy looks crispy sharp.

I had no idea that the transparent part of pngs affected performance. I've always just looked at image size and left it at that. Thank for the detailed explanation—my digital ads will be better for this.

Will you explain the calculation of 2400×2400 becoming 22MB image data?

I've never had the occasion to use webfonts in a banner, because client-specified fonts are always very specific and not common, like a Google font.

My go-to is PNGs processed thru ImageAlpha, which almost always results in smaller files than SVGs when I've compared. (At least at common banner sizes, 1200×1200 excepted.) I'd much rather use SVGs.

Do you find the same @BannerMan?

Yes if i can go the SVG route, I always take it.

Indeed in the smaller formats a png can be smaller at times. However, it bugs me that it never is as sharp as I want it to be due to compression. With SVG's that's never the case, always looking sharp. So i'd happily accept the 500/1000 bytes extra that a svg brings for clean shapes and text.


1200x1200 test (77,6 KB)

Duplicating the background and animating it makes it already much faster instead of fading in a bunch of text layers. This might not always work, though. So, it's not a general solution.


2,400 pixels wide :heavy_multiplication_x:2,400 pixels high :heavy_multiplication_x:4 bytes per pixel @ 8 bits per channel (RGBA) = 23,040,000 bytes ↴
23,040,000 bytes :heavy_division_sign:1,024 bytes per killobyte :heavy_division_sign: 1,024 killobytes per megabyte = 21.97 MB

There can be quite a bit more nuance to this given the relationship between image depth, browsers, operating systems, RAM storage locations, and GPUs, but it is a rough formula to consider with image sizing. Really to figure out actual memory usage you probably need to be profiling the browser itself along with the GPU; I'm not sure browser tools even give quite enough data here.

In regards to SVGs -- they can be both smarter and dumber about when to redraw and allocate memory. Many SVGs also unwittingly include bitmap data, since tools that were not produced specifically for the SVG format may implement incompatible feature sets that can only be represented as images. Very grossly speaking, a hype document chocked full of SVGs (like hundreds) probably will run into more performance trouble than that of PNGs. I'm not saying don't give it a try - quite the opposite since it could help in this situation - just that there's no single solution to performance problems. It is always content dependent and must always be tested/measured.


That's pretty ingenious

Fantastic. I want a wiki of your brain.

1 Like