Live data from Hacker News

60 FPS Animations with CSS3

medium.com

21–30 of 79 posts

Re: 60 FPS Animations with CSS3

#21
post #2

I hope browser vendors take note and make this guide obsolete.

This guide will be relevant until OS compositors fundamentally change from just dealing with bitmaps. Which is unlikely to happen anytime soon. And doing UI layout on background threads breaks the basic design of pretty much every UI framework, web or native, which are usually single-threaded.

That's not true at all. You don't have most of these problems when dealing with native apps, for example, and the reason is that browser rendering is just extremely slow. Thus the gap between the common path and the fast path is unusually massive on browsers.

It will get better when things like this: https://bugs.chromium.org/p/chromium/issues/detail?id=591179... get marked fixed (aka, use GPU rendering everywhere)

Although browsers needing to be highly defensive doesn't help, either. If a native app renders slow you generally blame the app, whereas if a website is slow you blame the browser (regardless of who is actually at fault). This leads to browser being conservative and defensive in their graphics stacks so that scrolling can be smooth in the face of graphically intense rendering.

OS composition is unrelated entirely here, and really there's no need for that to change away from just dealing with pixmaps.

Re: 60 FPS Animations with CSS3

#22
post #17

Earlier quoted context omitted.

This appears to be browser specific. I copied his code-pen and used his first example in Safari (just using the `left` css property) and it was still 60 FPS in Safari (per debugging tools). I wonder how much variance there is between browsers on this. (I'm on a Mac 10.12.5 using Safari 10.1.1 (12603.2.4))

There are a lot of jsperf tests like this one https://jsperf.com/translate3d-vs-xy/4 This isn't pure css as it's using JS to set the property, but it should be a good indicator.

I'm not an expert in this area, but doesn't setting these properties only take effect in the next layout/paint cycle?

I think you need to call getComputedStyle (https://developer.mozilla.org/en-US/docs/Web/API/Window/getC...) to resolve the new style update outside of the layout/paint cycle.

But I'm not really sure to be honest

Re: 60 FPS Animations with CSS3

#23

"but the human eye can only see 30fps!"

Sarcasm doesn't carry well on the internet, if that was your intention (not all of us know everything about everything). Please refrain, specially on this board.

I don't know, I recognised the sarcasm right away, since the comment used quotes to distance the speaker from what was said.

If we're all formal all the time, it's going to be hard to welcome new people. It's important to make sarcasm obvious though (because it's difficult to express), so that newcomers who may not know that this is ridiculous can feel "in" on the joke, while learning something, and not being embarrassed.

Re: 60 FPS Animations with CSS3

#24
post #17

TL;DR These are the best css properties to animate with Position — transform: translateX(n) translateY(n) translateZ(n); Scale — transform: scale(n); Rotation — transform: rotate(ndeg); Opacity — opacity: n; I'll add in that translate3d is generally faster than the other translate options. There's some good performance info in the post and it's worth the short read.

This appears to be browser specific. I copied his code-pen and used his first example in Safari (just using the `left` css property) and it was still 60 FPS in Safari (per debugging tools). I wonder how much variance there is between browsers on this. (I'm on a Mac 10.12.5 using Safari 10.1.1 (12603.2.4))

All CSS advice around "this causes the creation of a compositing layer" is browser-specific. Chrome and Safari happen to have a particular compositing model but AFAIK there's nothing in the HTML spec that actually requires it.

Re: 60 FPS Animations with CSS3

#25

Earlier quoted context omitted.

Hmm... Wouldn't it be possible to address the problem at another level? For instance, when it's discovered that layout properties are being animated, see if it would be possible to create an equivalent effect in the compositing stage, if so, convert the layout position changes to transforms? I realize that would probably not be easy , but maybe still possible without major architectural changes?

Which thread are you going to do that work on? It's complicated because layout changes can cause new elements to be created. Elements can be really expensive to create.

That's the kind of thing that would cause a rejection: elements are gong to be created, so this can't be converted to compositing stage operations instead.

Dunno which thread—just an idea.

Re: 60 FPS Animations with CSS3

#26
On a slightly unrelated note: Can anyone recommend a good SVG animation course that I could take. Or a set of guides that walk you through doing SVG animations / typical workflows.

I took this[1] course over the weekend and didn't find it very helpful because of a lack of code walkthroughs.

[1] - https://www.lynda.com/Web-Development-tutorials/Advanced-SVG...

Re: 60 FPS Animations with CSS3

#27

My 2015 macbook pro will hit 150% CPU on basic SVG animation via CSS properties (like rotating an SVG element by setting `transform: rotate(90deg);`) even when using the best practices described in the article. This means long, slow CSS animation absolutely kills browser performance. Independent of your opinions on animation in the browser, is there a less CPU-intensive way to do SVG animation?

It's either just using SVG at all that's the problem or something in the SVG that's a problem. SVGs are generally not GPU rasterized since GPUs are really not built for paths. That's a whole research area in and of itself. There are things you can attempt depending on your browser, though, such as avoiding non-convex paths in the SVG. If you want good performance everywhere though the only real option is just don't u…

> GPUs are really not built for paths

I remember a whole slew of "accelerated 2D" cards in the mid-1990s that had faster Windows GDI performance than we have today for certain 2D operations such as path drawing (the regression was in Windows Vista when they moved all GDI operations to the CPU).

Re: 60 FPS Animations with CSS3

#28

Earlier quoted context omitted.

Sarcasm doesn't carry well on the internet, if that was your intention (not all of us know everything about everything). Please refrain, specially on this board.

I don't know, I recognised the sarcasm right away, since the comment used quotes to distance the speaker from what was said. If we're all formal all the time, it's going to be hard to welcome new people. It's important to make sarcasm obvious though (because it's difficult to express), so that newcomers who may not know that this is ridiculous can feel "in" on the joke, while learning something, and not being embarra…

Yes, I noted the quotes but the comment was still useless because it doesn't add anything really informative here. Also, further muddying the water (of course after my comment) was your sibling comment which says anything above 30fps is a waste of priority.

Re: 60 FPS Animations with CSS3

#29

My 2015 macbook pro will hit 150% CPU on basic SVG animation via CSS properties (like rotating an SVG element by setting `transform: rotate(90deg);`) even when using the best practices described in the article. This means long, slow CSS animation absolutely kills browser performance. Independent of your opinions on animation in the browser, is there a less CPU-intensive way to do SVG animation?

It's either just using SVG at all that's the problem or something in the SVG that's a problem. SVGs are generally not GPU rasterized since GPUs are really not built for paths. That's a whole research area in and of itself. There are things you can attempt depending on your browser, though, such as avoiding non-convex paths in the SVG. If you want good performance everywhere though the only real option is just don't u…

> SVGs are generally not GPU rasterized since GPUs are really not built for paths. That's a whole research area in and of itself.

It's not so much that GPUs aren't built for paths as that winding rules are not suited for parallelism. The solution is to use meshes instead of paths. This is my current area of work.

Re: 60 FPS Animations with CSS3

#30
post #2

I hope browser vendors take note and make this guide obsolete.

This guide will be relevant until OS compositors fundamentally change from just dealing with bitmaps. Which is unlikely to happen anytime soon. And doing UI layout on background threads breaks the basic design of pretty much every UI framework, web or native, which are usually single-threaded.

> This guide will be relevant until OS compositors fundamentally change from just dealing with bitmaps. Which is unlikely to happen anytime soon.

There is absolutely no reason why browsers have to use the native compositor for CSS. It's a bad fit, and browsers should stop doing it.

> And doing UI layout on background threads breaks the basic design of pretty much every UI framework, web or native, which are usually single-threaded.

That's why you have a render tree on a separate thread from the DOM. Look at how Servo does it (disclaimer: I work on Servo). We've proven that it works.

Post reply on HN