Hacker News Reader

Hacker News

Comment by pier25 | Hacker News Reader

Full thread

pier25

I was wondering why the animation was so stuttery and then I saw they are using setInterval for the animation...

Jesus it's 2020 at least use requestAnimationFrame!

https://flaviocopes.com/requestanimationframe/

View on HN

>I was wondering why the animation was so stuttery and then I saw they are using setInterval for the animation...

setInterval isn't the problem. He's animating the CSS position (top, left), which triggers a full reflow and causes the stuttering. Always animate with translate3d, which is GPU accelerated.

Ooh you could even animate with a css transition from one bounce to the next with a linear curve; then you don't run any JS per frame, only at the bounces.

The problem I think is that transitions have fixed amount of time, both long and short travels finish with the same amount of time giving a different velocity of movement. Also executing Javascript every frame is not that heavy

Executing JavaScript every frame is not that heavy, but if the main thread is blocked because of something that is, which may even be in another tab, the animation will stutter.

The animations built into the platform can run and remain smooth under a broader range of conditions, which is why they should be preferred if you don't need the level of control that running script via requestAnimationFrame gives you.

As someone who's new to front end and css is there a good resource on what properties are more costly, or which functions are newer and meant to be more performant like translate3d is mentioned as being gpu accelerated? I've seen mentions of reflow, repaint, and layout thrashing but not a comprehensive list of what functions are meant to replace what other ones, or relative cost of each function in common use cases. I've managed to grasp javascript fairly easily coming from python, but css seems like this obscure black box that I thought would be much easier to get a handle on.

I have no great answer to your question, and you might know this already, but while translate3d is indeed newer, it’s not a “new more performant” replacement for positioning with top/left using the position property.

It’s just another property which can sometimes be used to do what you could earlier only do with ‘position:’, but there are still many cases (the majority) you position things using the “old” position property.

They have different uses, and for that reason one also requires a reflow while the other does not.

opacity and transform (translate, scale, rotate and skew). That's mostly it.

https://www.html5rocks.com/en/tutorials/speed/high-performan...

>I've managed to grasp javascript fairly easily coming from python, but css seems like this obscure black box that I thought would be much easier to get a handle on.

All I can say is use it, a lot. CSS skills are more of a dark art than anything resembling engineering. And the only way you get good is by trial and error, learning what works best and why.

The key to animation on the web is to at all costs avoid using JavaScript to manipulate a DOM object on a tight timer. To achieve a smooth animation, you need between 24fps and 120fps depending on the device, so between 43 and 8 milliseconds to get everything done. Doing DOM stuff that fast is going to be a headache compared to using CSS animation or even using the Canvas API.

This looks like it’s just 2D so translate() would be enough, almost all of the functions under transform are GPU accelerated.

Yes, they are now. Initially, only translate3d was accelerated so there's a lot of code that uses that still for 2D animation.

That is not correct.

setInterval is definitely the main issue here, especially with a 30ms delay, 33 or 16 would at least give it a chance to sync with refresh rates. Absolutely positioned elements do not trigger reflow, as the element is removed from the normal document flow [1]. See my example in another comment.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/position#ab...

Regardless of whether there is a reflow, translate() allows you to do subpixel animation [0]. It will always be smoother than animating CSS position [1].

[0] https://css-tricks.com/tale-of-animation-performance/

[1] https://www.paulirish.com/2012/why-moving-elements-with-tran...

> It will always be smoother

Once you're hitting 60fps there is no difference in smoothness regardless of method.

But in reality, it looks better if you avoid subpixel values, as the image will flicker slightly; the frames not aligned with the pixel grid will suffer blur or distortion. Try setting speed to 0.1 in the example to see it wobble. The effect is noticeable even on hi-dpi screens.

Not saying you should animate anything using position these days, CSS transforms are certainly the right tool.

Or alternatively, write it as a CSS animation and modify it on collision.

Exactly. This is what CSS Animations [1] were made for. And you don't even need to do collision detection, as CSS can already alternate directions and loop infinitely.

https://bouncing-logo-css.glitch.me/

Just needed a tiny bit of JS to set the sizes and randomise the logo colour.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati...

Nice demo. I was curious how you were going to avoid collision -- my assumption was since the pattern wasn't a "single cycle" loop (whose total length presumably depends on the LCM of the width and height) that the animation setting would either need to be very complicated or changed periodically, but you cleverly sidestepped the whole problem by applying X and Y translations to different wrappers so they can each have their own fixed period: smart!

setTimeout would probably be fine if they used the diff in elapsed time between calls to derive the position deltas rather than assuming it is always going to be 30ms.

The source image is also pixelated[1]. Could've used a vector instead[2]

1. https://www.bouncingdvdlogo.com/logos/dvdlogo-01.png

2. https://www.brandsoftheworld.com/logo/dvd-video-0

It's a pretty simple page, setTimeout should work well enough. Is the interval too high?

The issue's not setTimeout. Even with requestAnimationFrame, you'd combine it with setTimeout to control framerate and cpu usage.

The issue is the css properties manipulated, as commented by another person.

It's not just about speed, it's about timing. With setInterval the alignment of the screen refresh and the code to update will quickly become out of sync and cause periods where 2 frames are the same.

Which causes visual tearing.

Your browser, as a regular desktop application, is almost certainly double buffered. You will never see tearing, but things can look temporally uneven.

I wrote my own version - seems to run smoother https://speets.ca/dvd/

It stutters for me, but less than the original.

It stutters on iGPU graphics but not on dGPU graphics, both on firefox.

Reply on news.ycombinator.com