3 ms·

I think you have a different idea of what gpu acceleration means here. When we say that animating transform and opacity is fast, it means that we can animate it

by sunnyps 11y ago

I think you have a different idea of what gpu acceleration means here. When we say that animating transform and opacity is fast, it means that we can animate it without rasterizing content over and over again i.e. only use composition. This is independent of how rasterization takes place. Rasterization itself can be gpu accelerated, Chrome has started doing this on mobile[1]. Animating other CSS properties such as font-size require us to rasterize new content on every frame of animation. That is the inherent reason for why it's slow. Again we can use the GPU for rasterization but we're still going to do it every frame instead of caching the result in a texture that's then composited over and over again. [1]: https://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization https://www.chromium.org/developers/design-documents/chromiu...

pcwalton 11y ago
I know how it works. I wrote much of the layout and graphics code for Servo and did the initial bringup of the compositor on Firefox Mobile. You shouldn't have to rasterize new content on every frame when you animate font-size (except for individual glyphs, but that's still quick, just a few ms, if you parallelize it—and even with techniques like SDFs and/or GPU vector graphics tricks like [1] you may not even need to do anything on the CPU). If you animate, say, margin-left, you should in most cases be doing essentially no work on the CPU, and you should be able to submit one draw call to repaint the page since all of the resources (images, glyphs, alpha masks, SVGs) should be cached in an atlas. It should be 1-2ms. Even animating something like border-top-width should be no resource changes and one draw call, exactly as fast as your compositor should do it. Optimally implemented, I believe there should be no difference between "rasterization" and "compositing". You're painting the same number of pixels, paying the same fragment shading and rop cost, either way. Caching fully rendered Web content in textures assuming that the cost of rasterizing that content is high isn't working very well, and I think it's not worth it. [1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/ http://wdobbie.com/post/gpu-text-rendering-with-vector-textu...
- cromwellian 11y ago
  Does using a font-atlas really deliver the same quality as fully hinted true-type fonts? Also, this demo doesn't really have any state changes in it. Wouldn't a more realistic example be of a UI that contains mainly different font weights and sizes, to better gauge the effects of all of the pipeline state changes. I agree that the browser should be more like a game engine, and less like an X11 buffered window system, in terms of just rasterizing faster enough to render 60fps. But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls.
  - pcwalton 11y ago
    > Does using a font-atlas really deliver the same quality as fully hinted true-type fonts? Hinting really isn't important on mobile or HiDPI. In fact, no version of OS X or iOS does it. (I don't know about Android, but I wouldn't be surprised if it doesn't on HiDPI screens.) What's more interesting is antialiasing quality, especially subpixel AA. That's something I think needs more investigation. But I'm cautiously optimistic; there's been some really exciting work in GPU AA and vector graphics lately :) > Wouldn't a more realistic example be of a UI that contains mainly different font weights and sizes, to better gauge the effects of all of the pipeline state changes. Don't change state then. :) State changes really shouldn't be necessary. If you set things up properly, you should be able to render arbitrarily many glyphs with one draw call, bound only by your texture atlas size. > But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls. They typically don't. The key is to render critical resources like that to a texture atlas and to batch like resources together as you do so. (For example, batch all box shadow pieces together into one draw call, batch all rounded corners into another, etc.) This effectively places a small fixed upper bound on the number of draw calls you issue. Then you can rerender the page for each animation frame with a very small number of draw calls (frequently just one) and a simple blitting shader. If you get your draw call/state change overhead down, essentially nothing on the Web comes close to taxing a modern GPU; GPUs are incredibly fast at rendering batches. My talk goes into more details, if you're curious: https://air.mozilla.org/bay-area-rust-meetup-february-2016/ https://air.mozilla.org/bay-area-rust-meetup-february-2016/

by sunnyps 11y ago

pcwalton 11y ago

I know how it works. I wrote much of the layout and graphics code for Servo and did the initial bringup of the compositor on Firefox Mobile. You shouldn't have to rasterize new content on every frame when you animate font-size (except for individual glyphs, but that's still quick, just a few ms, if you parallelize it—and even with techniques like SDFs and/or GPU vector graphics tricks like [1] you may not even need to do anything on the CPU). If you animate, say, margin-left, you should in most cases be doing essentially no work on the CPU, and you should be able to submit one draw call to repaint the page since all of the resources (images, glyphs, alpha masks, SVGs) should be cached in an atlas. It should be 1-2ms. Even animating something like border-top-width should be no resource changes and one draw call, exactly as fast as your compositor should do it. Optimally implemented, I believe there should be no difference between "rasterization" and "compositing". You're painting the same number of pixels, paying the same fragment shading and rop cost, either way. Caching fully rendered Web content in textures assuming that the cost of rasterizing that content is high isn't working very well, and I think it's not worth it. [1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/ http://wdobbie.com/post/gpu-text-rendering-with-vector-textu...

cromwellian 11y ago
Does using a font-atlas really deliver the same quality as fully hinted true-type fonts? Also, this demo doesn't really have any state changes in it. Wouldn't a more realistic example be of a UI that contains mainly different font weights and sizes, to better gauge the effects of all of the pipeline state changes. I agree that the browser should be more like a game engine, and less like an X11 buffered window system, in terms of just rasterizing faster enough to render 60fps. But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls.
- pcwalton 11y ago
  > Does using a font-atlas really deliver the same quality as fully hinted true-type fonts? Hinting really isn't important on mobile or HiDPI. In fact, no version of OS X or iOS does it. (I don't know about Android, but I wouldn't be surprised if it doesn't on HiDPI screens.) What's more interesting is antialiasing quality, especially subpixel AA. That's something I think needs more investigation. But I'm cautiously optimistic; there's been some really exciting work in GPU AA and vector graphics lately :) > Wouldn't a more realistic example be of a UI that contains mainly different font weights and sizes, to better gauge the effects of all of the pipeline state changes. Don't change state then. :) State changes really shouldn't be necessary. If you set things up properly, you should be able to render arbitrarily many glyphs with one draw call, bound only by your texture atlas size. > But it seems like to me that the CSS spec contains a number of features (rounded corners, soft shadows, etc) that by themselves can be rendered fast on a GPU, but cobbled together in a complex scene graph might result in stalls. They typically don't. The key is to render critical resources like that to a texture atlas and to batch like resources together as you do so. (For example, batch all box shadow pieces together into one draw call, batch all rounded corners into another, etc.) This effectively places a small fixed upper bound on the number of draw calls you issue. Then you can rerender the page for each animation frame with a very small number of draw calls (frequently just one) and a simple blitting shader. If you get your draw call/state change overhead down, essentially nothing on the Web comes close to taxing a modern GPU; GPUs are incredibly fast at rendering batches. My talk goes into more details, if you're curious: https://air.mozilla.org/bay-area-rust-meetup-february-2016/ https://air.mozilla.org/bay-area-rust-meetup-february-2016/