5 ms·

I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't car

I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't care. This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there's stuff you have to avoid, or branching paths you have to handle to get good performance. If you use SQL databases, not all databases can handle all queries optimally. I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there's no slow paths. The practical reality is, there's always a subset of specs known to be fast and well supported and developers just need to know what that is.

pcwalton 11y ago
> I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't care. In the case of GPU acceleration, the specs are not broken. There is no fundamental reason why animations on arbitrary properties cannot be GPU accelerated and some can be. Ask anyone who's worked with Scaleform whether rapidly changing vector graphics (which is all these animations are) has to be slow on mobile. For style recalculation, maybe, maybe not; it's not clear to me that browsers are worse than native app frameworks here, except that we're missing Typed CSSOM, which is important spec work. > This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there's stuff you have to avoid, or branching paths you have to handle to get good performance. And game engine authors are fed up with it, which has led to Metal, DX12, and Vulkan. It's not a good way to treat developers; we should try to give them APIs in which, as much as possible, everything is fast. I think the Web APIs can be that, if implemented optimally. > I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there's no slow paths. I'm not saying that we have to pretend everything in HTML and CSS can be made equally fast. My point is that, in many areas, browsers have done a bad job of even trying to optimize broadly. Take animations, for example: the only thing browsers optimize is two properties out of hundreds, transform and opacity. This is exceptionally problematic, given that there's no technical reason why this has to be the case. I just gave a talk about this a few days ago :)
- 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

pcwalton 11y ago

> I think the browser specs are broken such there will always be pathological cases, and always cases where 'you're on the performance rails'. End users don't care. In the case of GPU acceleration, the specs are not broken. There is no fundamental reason why animations on arbitrary properties cannot be GPU accelerated and some can be. Ask anyone who's worked with Scaleform whether rapidly changing vector graphics (which is all these animations are) has to be slow on mobile. For style recalculation, maybe, maybe not; it's not clear to me that browsers are worse than native app frameworks here, except that we're missing Typed CSSOM, which is important spec work. > This is no different on any other platform. If you program games directly to OpenGL, for example, you run into all kinds of different bottlenecks, both CPU and GPU. Depending on the pipeline of the various GPUS, and what kinds of hazards they have, there's stuff you have to avoid, or branching paths you have to handle to get good performance. And game engine authors are fed up with it, which has led to Metal, DX12, and Vulkan. It's not a good way to treat developers; we should try to give them APIs in which, as much as possible, everything is fast. I think the Web APIs can be that, if implemented optimally. > I think it is asking too much of browsers to give them such a huge surface area spec as HTML and CSS, and then ask for them to optimize everything so there's no slow paths. I'm not saying that we have to pretend everything in HTML and CSS can be made equally fast. My point is that, in many areas, browsers have done a bad job of even trying to optimize broadly. Take animations, for example: the only thing browsers optimize is two properties out of hundreds, transform and opacity. This is exceptionally problematic, given that there's no technical reason why this has to be the case. I just gave a talk about this a few days ago :)

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