3 ms·

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

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

whowouldathunk 9y ago
> 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.
- pcwalton 9y ago
  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.
kllrnohj 9y ago
> 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 <video> 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.
panic 9y ago
> 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.
- pcwalton 9y ago
  > - 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.)
jcelerier 9y ago
> 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#threaded-render-loop-threaded http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#t...) (and also has no problem handling 1080p/60fps animations on embedded hardware)
- pcwalton 9y ago
  > Dunno about the others but Qt has a threaded render loop (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#t... 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. :)
- whowouldathunk 9y ago
  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.

whowouldathunk 9y ago

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

pcwalton 9y ago
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.

kllrnohj 9y ago

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

panic 9y ago

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

pcwalton 9y ago
> - 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.)

jcelerier 9y ago

> 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#threaded-render-loop-threaded http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#t...) (and also has no problem handling 1080p/60fps animations on embedded hardware)

pcwalton 9y ago
> Dunno about the others but Qt has a threaded render loop (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#t... 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. :)
whowouldathunk 9y ago
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.