Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

60 FPS Animations with CSS3

medium.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: 60 FPS Animations with CSS3

#31

Post by pcwalton »

westoncb wrote: post #15
whowouldathunk wrote: post #8

Earlier quoted context omitted.

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.

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?

> 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?

Yes, and we as browser vendors should absolutely do that.

Though a better solution is to just make the compositor able to accelerate the full generality of CSS in the first place.

Re: 60 FPS Animations with CSS3

#32

Post by pcwalton »

whowouldathunk wrote: post #18
westoncb wrote: post #15

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.

> Which thread are you going to do that work on?

The layout thread.

> It's complicated because layout changes can cause new elements to be created. Elements can be really expensive to create.

Huh? No, they can't. In rare cases, layout changes can cause new render objects to be created (line breaks), but that's not elements.

Re: 60 FPS Animations with CSS3

#33

Post by whowouldathunk »

kllrnohj wrote: post #21
whowouldathunk wrote: post #8

Earlier quoted context omitted.

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) A…

You have this problem with native Windows apps. I'm not familiar with iOS or Android.

https://blogs.msdn.microsoft.com/windowsappdev/2012/05/01/fa...

An independent animation is an animation that runs independently from thread running the core UI logic. (A dependent animation runs on the UI thread.)

The elements map directly to OS compositor "visuals."

Disclosure: I work at Microsoft

Re: 60 FPS Animations with CSS3

#34

Post by whowouldathunk »

pcwalton wrote: post #32
whowouldathunk wrote: post #18

Earlier quoted context omitted.

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.

> Which thread are you going to do that work on? The layout thread. > It's complicated because layout changes can cause new elements to be created. Elements can be really expensive to create. Huh? No, they can't. In rare cases, layout changes can cause new render objects to be created (line breaks), but that's not elements.

Not sure how Servo works, but what happens if a list viewport gets bigger and you need to display more list items?

Re: 60 FPS Animations with CSS3

#36

Post by modzu »

westoncb wrote: post #10
luke3butler wrote: post #5

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.

They also point out that substantial performance gains are given by using 'will-change,' as in the following. .app-menu { -webkit-transform: translateX(-100%); transform: translateX(-100%); transition: transform 300ms linear; will-change: transform; } And I'd point out that the authors are specifically stating that animating transform+opacity (via a 'transition') are more efficient than things like left, top, bottom,…

there are some caveats to note about the 'will-change' property that they do not mention:

https://developer.mozilla.org/en/docs/Web/CSS/will-change

Re: 60 FPS Animations with CSS3

#37

Post by whowouldathunk »

pcwalton wrote: post #30
whowouldathunk wrote: post #8

Earlier quoted context omitted.

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 s…

> There is absolutely no reason why browsers have to use the native compositor for CSS.

Sure, but you're basically re-implementing big parts of the OS in the browser. Which is maybe not a bad idea, but at some point there's inception.

Re: 60 FPS Animations with CSS3

#38

Post by kuschku »

whowouldathunk wrote: post #33
kllrnohj wrote: post #21

Earlier quoted context omitted.

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) A…

You have this problem with native Windows apps. I'm not familiar with iOS or Android. https://blogs.msdn.microsoft.com/windowsappdev/2012/05/01/fa... An independent animation is an animation that runs independently from thread running the core UI logic. (A dependent animation runs on the UI thread.) The elements map directly to OS compositor "visuals." Disclosure: I work at Microsoft

The same issues also happen on Android, which is why Android has separate threads for layouting and interactions, rendering, and business logic in every app, and why all complicated rendering ends up on separate GPU layers.

Re: 60 FPS Animations with CSS3

#39

Post by kllrnohj »

whowouldathunk wrote: post #33
kllrnohj wrote: post #21

Earlier quoted context omitted.

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) A…

You have this problem with native Windows apps. I'm not familiar with iOS or Android. https://blogs.msdn.microsoft.com/windowsappdev/2012/05/01/fa... An independent animation is an animation that runs independently from thread running the core UI logic. (A dependent animation runs on the UI thread.) The elements map directly to OS compositor "visuals." Disclosure: I work at Microsoft

I'm not as familiar with native windows apps anymore but the difference typically is that while there is a faster path on native it's not as critical that it's taken. As in, the slow path is still generally fast enough.

That certainly used to be true on win32 (in that an animation of left/top would easily hit 60fps on a desktop computer), but maybe Microsoft's UI toolkits have regressed significantly? I rather doubt it, though, and suspect that it would still work just fine on a native windows app even though the web equivalent grinds to a halt.

Re: 60 FPS Animations with CSS3

#40

Post by kllrnohj »

kuschku wrote: post #38
whowouldathunk wrote: post #33

Earlier quoted context omitted.

You have this problem with native Windows apps. I'm not familiar with iOS or Android. https://blogs.msdn.microsoft.com/windowsappdev/2012/05/01/fa... An independent animation is an animation that runs independently from thread running the core UI logic. (A dependent animation runs on the UI thread.) The elements map directly to OS compositor "visuals." Disclosure: I work at Microsoft

The same issues also happen on Android, which is why Android has separate threads for layouting and interactions, rendering, and business logic in every app, and why all complicated rendering ends up on separate GPU layers.

> and why all complicated rendering ends up on separate GPU layers.

No, it doesn't. The app renders to a single surface in a single GPU render pass unless the app uses a SurfaceView, which is generally only for media uses (camera, video, games).

Multiple layers are only used when asked for explicitly (View.setLayerType) or when required for proper blending. They are generally avoided otherwise as it's generally slower to use multiple layers.

You can absolutely do the "bad" things in the linked article in a native Android app and still hit 60fps pretty trivially. The accelerated properties, like View.setTranslationX/Y, only bypass what's typically a small amount of work (and don't use a caching layer). It's an incremental improvement, not something absolutely required. Scrolling in a RecyclerView or ListView, for example, doesn't even do that. It just moves the left/top of every view and re-renders, and that's plenty fast to hit 60fps.

Post reply on HN