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

51–60 of 79 posts

Re: 60 FPS Animations with CSS3

#51

Post by pcwalton »

jcelerier wrote: post #49
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…

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

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

Largely written by Glenn Watson, the primary author of Servo's WebRender, no less. :)

Re: 60 FPS Animations with CSS3

#52

Post by michaelchisari »

jdauriemma wrote: post #48

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

A nice feature would be to add an "energy saver" option to your web app, which adds a class to your app and a stylesheet that disables all animations.

Re: 60 FPS Animations with CSS3

#53

Post by whowouldathunk »

jcelerier wrote: post #49
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…

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

By "single-threaded" I meant business logic and non-fixed layout being done on the same thread. "Rendering" (drawing to a bitmap or translating to the OS compositor's object model or direct OpenGL/DirectX/etc.) is done on a separate thread in most frameworks I'm aware of.

Re: 60 FPS Animations with CSS3

#54

Post by panic »

pcwalton wrote: post #50
panic wrote: post #44

Earlier quoted context omitted.

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

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

You still have to swap buffers from your background thread and then composite the buffer instead of compositing the animating layer directly. It's a small advantage, but it is an advantage.

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

https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-fi... (yes, it's an experimental property, but it's the one I was thinking about)

Re: 60 FPS Animations with CSS3

#55

Post by kllrnohj »

kuschku wrote: post #47
kllrnohj wrote: post #40

Earlier quoted context omitted.

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

I think your confusing the RenderThread with GPU layers. There's only 1 rendering thread per app and it handles all rendering work done by that app. It's really no different than pre-M rendering other than a chunk of what used to be on the UI thread is now on a different thread. The general flow is the same.

The new part is that some animations (basically just the Ripple Animation) can happen on their own on that thread, but it doesn't use a GPU layer for it nor a different OS composition layer.

Re: 60 FPS Animations with CSS3

#56

Post by kuschku »

kllrnohj wrote: post #55
kuschku wrote: post #47

Earlier quoted context omitted.

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.

I think your confusing the RenderThread with GPU layers. There's only 1 rendering thread per app and it handles all rendering work done by that app. It's really no different than pre-M rendering other than a chunk of what used to be on the UI thread is now on a different thread. The general flow is the same. The new part is that some animations (basically just the Ripple Animation) can happen on their own on that thr…

> but it doesn't use a GPU layer for it nor a different OS composition layer.

Really? As so often, there was a lot of talk about doing that beforehand, and it wasn’t discussed at all later on, so I had assumed that this had been done. Interesting that this didn’t happen.

What’d be the reason for that? Animating objects on a static background seems a prime case for GPU layers. Or was it the issue with the framebuffer sizes being too huge again?

Re: 60 FPS Animations with CSS3

#58

Post by pcwalton »

panic wrote: post #54
pcwalton wrote: post #50

Earlier quoted context omitted.

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

> 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). You still have to swap buffers from your background thread and then composite the buffer instead of compositing the animating layer directly. It's a small advantage, but it is an advantage. > If you're talking about CSS filters, ther…

> You still have to swap buffers from your background thread and then composite the buffer instead of compositing the animating layer directly. It's a small advantage, but it is an advantage.

By this I assume you mean that when you have two compositors, you have an extra blit. This is mostly true (though it's not necessarily true if the OS compositor is using the GPU's scanout compositing), but it's by no means worth the enormous downsides of current layerization hacks. Right now, when you as a Web developer fall off the narrow path of stuff that the OS compositor can do, your performance craters. The current status quo is not working: only about 50% of CSS animations in the wild are performed off the main thread.

There's another enormous downside to using the OS compositor: losing all Z-buffer optimizations. Right now, browsers usually throw away 2x or more of their painting performance painting pixels that are occluded. When using the OS compositor, the browser painting engine doesn't know which pixels are occluded, because that's something only the OS compositor knows, so it has to paint the contents of every buffer just in case. But with a smart CSS compositor, the browser can early Z-reject pixels covered up by other elements.

> yes, it's an experimental property, but it's the one I was thinking about

Ah, OK, I wasn't aware of that because it's only implemented in Safari right now. Well, using the OS compositor would make it easier to apply backdrop filters, as long as the OS compositor supports everything in the SVG filter spec (a big assumption—I suspect this is only the case on macOS and iOS!) But even with that, I think it results in less complexity to just use the OS compositor for this specific case and fall back on the browser compositor for most everything else, just as with video. CSS really does not map onto OS compositors very well.

Re: 60 FPS Animations with CSS3

#59

Post by moosingin3space »

pcwalton wrote: post #29
kllrnohj wrote: post #19

Earlier quoted context omitted.

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.

Is this the generalization of the Pathfinder text renderer?

Re: 60 FPS Animations with CSS3

#60

Post by Sohcahtoa82 »

rootedbox wrote: post #6
xyzxyz998 wrote: post #4

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 can't actually tell if you are being sarcastic.. As he actually has a point. If you're spending your time getting to make your hamburger work past 30 fps; then you may need to rethink priorities.

For a simple web app, yeah, I'd agree that trying to get over 30 fps is pointless, especially on mobile where I'll be concerned about battery usage.

But for gaming, anybody that can't tell the difference between 30 fps and 60 fps is blind. I have a 144 hz monitor, and I can certainly tell the difference even between 60 fps and 144 fps.

The UFO Test [0], while contrived, will show you the difference. If you have a 60 hz monitor, it will show things moving at 60 fps and 30 fps (And 15 and 7.5 fps, if you want). If you have a 144 hz monitor, it will show 144 fps, 72 fps, 36 fps, etc. The difference is clear, especially if you're following the UFO with your eyes. The higher framerate is less blurry. In games, this can be huge.

[0] https://www.testufo.com/#test=framerates

Post reply on HN