60 FPS Animations with CSS3 • Hacker News Board

Re: 60 FPS Animations with CSS3

#41

Post by pcwalton » Mon, Jul 10, 2017, 7:19 PM UTC

whowouldathunk wrote: post #34

pcwalton wrote: post #32

Earlier quoted context omitted.

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

The newly visible list items are already laid out, so we just display them.

Re: 60 FPS Animations with CSS3

#42

Post by kllrnohj » Mon, Jul 10, 2017, 7:20 PM UTC

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. It's a bad fit, and browsers should stop doing it.

Not entirely true. It's pretty critical to use the OS compositor for for power reasons so that video playback can be offloaded entirely.

For everything else, though, agree. The OS compositor isn't magic and at the end of the day doesn't do much for non-video layers.

Re: 60 FPS Animations with CSS3

#43

Post by pcwalton » Mon, Jul 10, 2017, 7:21 PM UTC

whowouldathunk wrote: post #37

pcwalton wrote: post #30

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

There's a good reason to, in this case: that the OS compositor is not designed to render the full generality of CSS.

The status quo is not working: only about half of CSS animations in the wild run on the compositor. As browser vendors, we need to admit that the attempt to carve out a limited, fast subset of CSS has failed, and we should do the hard work to make all of CSS run fast.

Re: 60 FPS Animations with CSS3

#44

Post by panic » Mon, Jul 10, 2017, 7:30 PM UTC

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. It's a bad fit, and browsers should stop doing it.

Here are a few:

- On some platforms, animations on native layers are applied every frame, even if the application that owns the layer is busy. This means fewer opportunities to drop frames.

- Sometimes web rendering engines are embedded in apps. Your app may want to draw web content that filters some other content that's behind it. This content may not be available to the browser engine (it may be in a separate process, for example). A native layer can apply this filter in the compositor process, where the content is available.

- Using the native compositor makes it easier to embed components (like video) that are provided by the system as native layers.

Re: 60 FPS Animations with CSS3

#45

Post by russellbeattie » Mon, Jul 10, 2017, 7:39 PM UTC

Animations via CSS have been a challenge in my experience. It's easy to create a demo with a single layer of DOM elements and have it work well, but as soon as there is overlap of any sort, lots of DOM elements to manipulate, or things like images or media, it can get twitchy real fast. In addition, every browser and every platform is different in rand ways.

I was doing testing on a scrolling carousel and couldn't figure out what was causing a stutter that appeared in an Android WebView, but not in the equivalent Chrome version on a Mac. It turned out that the desktop browser was doing an additional recalc in the middle of a bunch of other animations. I ended up slotting in a document.body.getBoundingClientRect() to force the recalc and make them work equivalently. You might think this would cause thrashing, but it actually smoothed things out. Crazy but true.

Also, CSS animations can "cancel" in odd ways... if I tell an element to translateX from a to b, then during the animation, tell it to actually go to c, some browsers will figure it out (most) and do the right thing, some will "start over", some will do wonky things with the speed (does it calculate the duration from the current position in between a and b, or from a?).

Don't get me wrong, CSS3 animations are great, but don't make the mistake that they "just work", because they don't.

Re: 60 FPS Animations with CSS3

#46

Post by whowouldathunk » Mon, Jul 10, 2017, 7:49 PM UTC

kllrnohj wrote: post #39

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

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…

Animating left/top on a fixed layout is indeed still fast. But modern app layouts using responsive design are still going to need to hit the UI thread to modify controls as the size changes.

Re: 60 FPS Animations with CSS3

#47

Post by kuschku » Mon, Jul 10, 2017, 8:16 PM UTC

kllrnohj wrote: post #40

kuschku wrote: post #38

Earlier quoted context omitted.

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

This used to be true, but since Android M and N, where a lot more animations were added, a lot of animation now happens on separate GPU layers (and is rendered, if necessary, by separate threads).

This was especially necessary due to many of the ripple animations being introduced.

Re: 60 FPS Animations with CSS3

#48

Post by jdauriemma » Mon, Jul 10, 2017, 8:17 PM UTC

This article was useful and concise.

I urge web developers to consider the trade-offs when using CSS hardware acceleration. Properties like `will-change` or `transform3d` substantially increase the client device's energy usage. This has battery-life implications for users on portable devices such as laptops, tablets, and mobile phones. As with any other feature, ask "why" before "how" when prioritizing interactive motion in your webapp.

More info: https://dev.opera.com/articles/css-will-change-property/

Re: 60 FPS Animations with CSS3

#49

Post by jcelerier » Mon, Jul 10, 2017, 8:35 PM UTC

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…

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

Dunno about the others but Qt has a threaded render loop (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#t...) (and also has no problem handling 1080p/60fps animations on embedded hardware)

Re: 60 FPS Animations with CSS3

#50

Post by pcwalton » Mon, Jul 10, 2017, 8:49 PM UTC

panic wrote: post #44

pcwalton wrote: post #30

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. 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. It's a bad fit, and browsers should stop doing it. Here are a few: - On some platforms, animations on native layers are applied every frame, even if the application that owns the layer is busy. This means fewer opportunities to drop frames. - Sometimes web rendering engines are embedded in apps. Your app may want to draw web conte…

> - On some platforms, animations on native layers are applied every frame, even if the application that owns the layer is busy. This means fewer opportunities to drop frames.

The browser can and should do the same with its CSS compositor. There's no reason why the CSS compositor should run on the main thread (and, in fact, no modern browser works this way).

> - Sometimes web rendering engines are embedded in apps. Your app may want to draw web content that filters some other content that's behind it. This content may not be available to the browser engine (it may be in a separate process, for example). A native layer can apply this filter in the compositor process, where the content is available.

For transparent regions, a browser can do this by simply exporting its entire composited tree as a single transparent layer, where it can be composited over other content. In the case of a single-layer page, this is what the browser is doing anyway.

If you're talking about CSS filters, there's no way that I know of in CSS to say "filter the stuff behind me" in the first place. You can only filter elements' contents.

> - Using the native compositor makes it easier to embed components (like video) that are provided by the system as native layers.

I grant that you have to use the native compositor to get accelerated video on some platforms. But that doesn't mean that a browser should do everything this way. In fact, no browser even tries to export all of CSS to the compositor: this is why you have the various "layerization" hacks which give rise to the sadness in this article. Reducing what needs to be layerized to just video would actually decrease complexity a lot over the status quo. (If you don't believe me, try to read FrameLayerBuilder.cpp in Gecko. It would be way simpler if video were the only thing that generated layers.)