Animation: To use proportional Scale or Width/Height properties?

Hello everyone,

I noticed when comes to animating image width and height it runs a bit slower and almost stutters? However, when comes to scaling proportionally it doesn’t but blurs an image in someways?

Also, Is it me or is GreenSock ‘tweenmax…’ and Adobe Animates canvas js libraries are slightly faster and smoother when it comes to animation side of things?

width/height always re-renders content and only uses integral pixel values so slow movement can look choppier since it doesn't interpolate fractional pixels. Scale will re-render in some cases (in fact Hype tries very hard to have it do this so things continue to look sharp) but there are some cases (3d rotation, filter effects, maybe some others) where it will use the bitmap contents as they were originally rendered to do the scaling, and this can result in it looking blurry when scaled up.

Feel free to send any specific tweenmax animations that you think are smoother and I can take a look. Hype's engine does a lot more than tweenmax though. Canvas is a different drawing technology and likely has very different performance characteristics.


Heres one from Home Depot and Whirlpool

Do you have anything head-to-head? While the text effects don’t have automation, I have a hard time believe Hype’s animation engine would be noticeably different – if anything I found some of the animations at the end to not look as smooth as I’d expect from Hype!

In my experience, a very similar or exactly the same animation will work perfect made with Hype. In many web browsers, on many devices. If wanted, with responsive behaviours as well.

1 Like

Hi Thomas and @Jonathan,

Based on my observation and me dealing with ads that are being served to google ads or google double click for publishers the ads show up, but with slight hiccups or not as smooth? I know it sounds strange, but please when you have a minute visit the site Sonicscoop keep refreshing until you see ads by B&H The Professionals Source and focus your attention on the 728x90 variant towards the top additionally, if you scroll down you might randomly see ads that are in the sizes of 300x250, 300x600 on the right hand side. I know what you might be thinking, it can very well be multiple instances of ads running at the same time whether one at the bottom or on the side thereby too many requests are made to the server side so the processing maybe a tad slower? I’ve actually seen just the one of our ads show up and it was still a bit choppy or not as smooth as the original ones? I wonder what can it be?

I tried to upload a screen recording quicktime .mov file @ 3megs but the forum didnt allow it

The originals are below and very smooth. (1.4 KB) (1.4 KB) (1.4 KB)

When it comes to Best Buys ads they are always smooth even if multiple instances are running in different sizes within one page btw they utilize Adobe Animate for their ads. An interesting note, Majority of ads that are made are using Greensock js library’s and they’re smooth as can be loaded in with multiple sizes in open still smooth.

As for creating ads that are responsive and have layout breakpoints I’m aware of it. Ive done so many including the one below. Though generally speaking you are correct its a very useful feature being able to have many layouts. This is why I/we turned to Hype amongst other features Tumult infused the application with. (1.2 KB)

Thanks for your time.

I can definitely see some hiccups running on that site. It is fine when running solo. I took a profile in chrome:

The section I highlighted is where I saw a lot of initial frames dropped. In this time, the page is hung up:

  • parsing the listbuilder-popup.css
  • running sumo JS code (index)
  • running code from services.js
  • running code from osd.js
  • repainting/recompositing quite a bit

The actual Hype traces in there are a few tiny slivers :slight_smile:.

Those items are all running on the main thread and taking away Hype, or any other javascript, from firing. I did not see any other ads that were animated on that page so I can’t do a head-to-head comparison. If you can put other tool’s animated ads that animate immediately on the page I’d like to see that. Most of the stuttering happens while the page is still loading and is still within the first second or so - this would mean you’d never see it with the best buy ad.

The only technological workaround would be to use CSS animations/transitions, since browsers typically don’t mind doing a repaint/render while running JS with that technology. However neither Hype, greensock, nor animate use this - we’re all JS-based and would be subject to the same items on the page causing issues.

My recommendation would be to delay animations by a little bit to account for page loading. It isn’t clear if the other JS/CSS parsing is coming from within your ad code; if it is I’d try eliminating that. Regardless in an ad environment there’s definitely going to be items on the page you have no control over.

I’m happy to look at any other head-to-head examples that you can bring up. (And if so, please include zips of the .hype and other tool files - )

What a great observation Jonathan, thank you! So the answer to your response - If they have any other html ads running head to head on the site? Sadly, We’re the only ones that are serving html hype ads made for the dfp. They were thrilled we were their first client to run html files vs age old gifs.
I’m reading about browser requests and I’m trying to formulate a plan of action so in the future I know whats at stake. There are ads that are showed at random on sonic scoops site and @Daniel mentioned if I use hypes cdn library for caching It can speed up the animations if multiple ads are running that is, but do you think it will solve the current problem? I’ll make pan animation slower great suggestion!

As for ads that I’ve seen on different sites such as Best Buy’s you can actually see for yourself if you go to Best Buy they’ll retarget you if you go to a different site that serves google ads sometimes they came up in three different size and all smooth you might need to turn tracking on.

No, that won’t solve the current problem - @Daniel’s suggestion will increase initial load speed for showing ads by reducing the amount downloaded. The main culprits on that page is parsing non-add CSS and executing non-ad javascript. These operations tend to happen as single threaded execution, so Hype animations need to wait to draw until they are done. The only ways to solve the problem are to try to avoid when other JS runs (the easiest method is introducing a delay and hoping it is long enough that the page has settled down) or by having the ad run on faster computers ;).


What would be an easy fix to delay image loading and javascript execution within the Hype part of the page?

So you mean delaying the initial timeline animation to start after 2-3 seconds on viewport enter? Essentially giving those js files a chance load and then start the ad animation? I can give that a shot. I wonder if I can add a script to load the ad after so all of the requests are made and have them be loaded js's to the DOM and then only then start it, unsure if its a possibility at this point.

Im wondering if this would make sense?

Keep in mind that loading the page has more than one stage. Btw, this is pure JavaScript


This event is fired when the initial HTML document has been completely loaded and parsed , without waiting for stylesheets, images, and subframes to finish loading. At this stage you could programmatically optimize loading of images and css based on user device or bandwidth speed.

Exectues after DOM is loaded (before img and css):

document.addEventListener("DOMContentLoaded", function(){

Note: Synchronous JavaScript pauses parsing of the DOM. If you want the DOM to get parsed as fast as possible after the user requested the page, you could turn your JavaScript asynchronous and optimize loading of stylesheets


A very different event, load , should only be used to detect a fully-loaded page . It is an incredibly popular mistake to use load where DOMContentLoaded would be much more appropriate, so be cautious.

Exectues after everything is loaded and parsed:

window.addEventListener("load", function(){
    // ....
1 Like

Might just what I need, thank you!

You asked last night if the CDN I setup would do anything for a page with multiple animations and I said yes. It seems you might be up against the amount of JavaScript & render blocking on that page.

I recommend using Youtube and setting your video to be 'unlisted' for larger files.

You can try load or DOMContentLoaded, but my guess is it is going to be early. Looad is an event saying (roughly) that everything statically defined has loaded. Also the ad is in an iframe and so you’re not looking at the actual page events; you’d need to do that. The reason IAB ads want that event is to not have a page hold up normal loading. But that page has a lot of deferred downloading/parsing/rendering/code that is just so happening early, but after that event. There’s really no deterministic way to know if a page is ready because at any time scripts can have a timer callback, an async file can finish loading and kick off item, and so on.