4 ms·

Then it means Chrome was not modern enough at that time. Here is what happens in my Sciter: http://sciter.com/screenshots/css-transform.png http://sciter.com/s

by c-smile 10y ago

Then it means Chrome was not modern enough at that time. Here is what happens in my Sciter: http://sciter.com/screenshots/css-transform.png http://sciter.com/screenshots/css-transform.png As you see the rendering is made in vector form, not as a bitmap rotation.

nostrademons 10y ago
Chrome has both the advantage and the curse of working with the rest of the web. That means they can't break existing CSS properties, and any GPU rendering needs to work with every existing website out there. The constraints they are under are much more restrictive than the constraints you are under. There was a project to go all-GPU rendering within Chrome when I left, but it was a big project, and I don't know if they ever finished it. Even if they did, that still doesn't speak for WebKit/Edge/Firefox/Servo. (Edge is usually pretty modern when it comes to GPU acceleration, and I've heard Servo is heading this way, but Apple has historically cared very little about animation performance on WebKit, instead hoping to drive people to write native iOS apps.)
- c-smile 10y ago
  You don't need to break the web to implement per-primitive transformations. Safari, FF, IE do them per-primitive for example. The only case when transformation are made on bitmap buffers is then 3D transformations are involved. Everyone knows how to do per-primitive 2D transformations these days.
  - nostrademons 10y ago
    Pretty sure I still get aliasing artifacts on Safari (and Chrome). Firefox has smooth text but seems to have artifacts on the gradient: https://jsfiddle.net/nqaoq52n/3/ https://jsfiddle.net/nqaoq52n/3/ If I run it through Chrome's Timeline inspector, the majority of the time in each animation frame is spent on the GPU (0.32 ms), while Paint only takes 0.01ms and Composite Layers is 0.03ms (there're also fairly lengthy 0.13ms Recalc Styles and 0.22 Update Layer Tree phases, where I suspect it's walking the whole JSFiddle DOM to find out nothing has changed). If I run it through Firefox's profiler, there is a lengthy Paint (~8ms), followed by only Recalc Styles per animation frame (I'm guessing that it's doing everything on the GPU and the profiler doesn't show me that work), except when the element grows enough to force a scroll bar to appear, which trigger a re-layout.
    - pcwalton 10y ago
      > where I suspect it's walking the whole JSFiddle DOM to find out nothing has changed No browser does this.
- pcwalton 10y ago
  > Edge is usually pretty modern when it comes to GPU acceleration, and I've heard Servo is heading this way, but Apple has historically cared very little about animation performance on WebKit, instead hoping to drive people to write native iOS apps This isn't really an accurate description of the current state of affairs. Edge, Firefox, Chrome, and Safari all use essentially the same architecture for rendering. In the case of all browsers but Chrome and Firefox on non-Windows platforms, they are already doing all their rendering using vector graphics APIs that are GPU-assisted (Direct2D for Edge and Firefox; CG::OGL for Safari); at least on Windows, Chrome is the last one to catch up here. All browsers use a "paint"/"compositor" distinction, which leads to the "transform/opacity is fast, other CSS properties are slow" effect. In the case of Safari, the compositor is run by the OS window server (Core Animation); Chrome is heading this way too on Mac. For other browsers and OS's, the compositing is done by the browser itself. This design, which essentially all shipping browsers share, is motivated not by Web compatibility concerns but rather because it was easy to retrofit onto older browser engines. Servo does things differently: it removes the distinction between painting and compositing, replacing it with WebRender, an integrated solution that handles both. This means that it can run animations off the main thread and GPU-accelerate all of them, not just transform and opacity. The legacy vector graphics APIs are cut out of the picture entirely (except for SVG/canvas), which results in a much more optimized graphics pipeline. We do not break the Web while doing so; there is nothing in the spec that requires the use of legacy vector graphics APIs when painting Web content.

by c-smile 10y ago

nostrademons 10y ago

Chrome has both the advantage and the curse of working with the rest of the web. That means they can't break existing CSS properties, and any GPU rendering needs to work with every existing website out there. The constraints they are under are much more restrictive than the constraints you are under. There was a project to go all-GPU rendering within Chrome when I left, but it was a big project, and I don't know if they ever finished it. Even if they did, that still doesn't speak for WebKit/Edge/Firefox/Servo. (Edge is usually pretty modern when it comes to GPU acceleration, and I've heard Servo is heading this way, but Apple has historically cared very little about animation performance on WebKit, instead hoping to drive people to write native iOS apps.)

c-smile 10y ago
You don't need to break the web to implement per-primitive transformations. Safari, FF, IE do them per-primitive for example. The only case when transformation are made on bitmap buffers is then 3D transformations are involved. Everyone knows how to do per-primitive 2D transformations these days.
- nostrademons 10y ago
  Pretty sure I still get aliasing artifacts on Safari (and Chrome). Firefox has smooth text but seems to have artifacts on the gradient: https://jsfiddle.net/nqaoq52n/3/ https://jsfiddle.net/nqaoq52n/3/ If I run it through Chrome's Timeline inspector, the majority of the time in each animation frame is spent on the GPU (0.32 ms), while Paint only takes 0.01ms and Composite Layers is 0.03ms (there're also fairly lengthy 0.13ms Recalc Styles and 0.22 Update Layer Tree phases, where I suspect it's walking the whole JSFiddle DOM to find out nothing has changed). If I run it through Firefox's profiler, there is a lengthy Paint (~8ms), followed by only Recalc Styles per animation frame (I'm guessing that it's doing everything on the GPU and the profiler doesn't show me that work), except when the element grows enough to force a scroll bar to appear, which trigger a re-layout.
  - pcwalton 10y ago
    > where I suspect it's walking the whole JSFiddle DOM to find out nothing has changed No browser does this.
pcwalton 10y ago
> Edge is usually pretty modern when it comes to GPU acceleration, and I've heard Servo is heading this way, but Apple has historically cared very little about animation performance on WebKit, instead hoping to drive people to write native iOS apps This isn't really an accurate description of the current state of affairs. Edge, Firefox, Chrome, and Safari all use essentially the same architecture for rendering. In the case of all browsers but Chrome and Firefox on non-Windows platforms, they are already doing all their rendering using vector graphics APIs that are GPU-assisted (Direct2D for Edge and Firefox; CG::OGL for Safari); at least on Windows, Chrome is the last one to catch up here. All browsers use a "paint"/"compositor" distinction, which leads to the "transform/opacity is fast, other CSS properties are slow" effect. In the case of Safari, the compositor is run by the OS window server (Core Animation); Chrome is heading this way too on Mac. For other browsers and OS's, the compositing is done by the browser itself. This design, which essentially all shipping browsers share, is motivated not by Web compatibility concerns but rather because it was easy to retrofit onto older browser engines. Servo does things differently: it removes the distinction between painting and compositing, replacing it with WebRender, an integrated solution that handles both. This means that it can run animations off the main thread and GPU-accelerate all of them, not just transform and opacity. The legacy vector graphics APIs are cut out of the picture entirely (except for SVG/canvas), which results in a much more optimized graphics pipeline. We do not break the Web while doing so; there is nothing in the spec that requires the use of legacy vector graphics APIs when painting Web content.