4 ms·

> Is CSS effectively "free", or is this just not a complex-enough example to start to see problems? Far from being "free" unfortunately. Especially if it is ma

by c-smile 10y ago

> Is CSS effectively "free", or is this just not a complex-enough example to start to see problems? Far from being "free" unfortunately. Especially if it is made on CPU side. But modern browsers are trying to use GPU for that. GPU has a primitive operation: render triangle with three colors at corners. So for non-trivial gradients you will need (on CPU side) to do so called triangulation to produce meshes containing such triangles: http://www.svgopen.org/2011/papers/18-Advanced_Gradients_for_SVG/triangle.png http://www.svgopen.org/2011/papers/18-Advanced_Gradients_for.... And then you need to send that mesh to GPU for batch rendering. Quite complex machinery. Flash and Java were trying to do all that on CPU side. But with high DPI monitors (like 300 PPI Retina - 9 times more pixels on screens) CPU rasterization is not the option anymore.

nostrademons 10y ago
For animations that touch only primitive transformations (scale/translation/rotation/opacity), the browser will usually render the element once on CPU, upload it to the GPU as a texture, and then composite it with the rest of the page on the GPU. That makes things like the spinning BB-8 or the blinking NO VACANCY basically free on the CPU.
- c-smile 10y ago
  I believe you are wrong. Usually browsers render all primitives as they are but with transformations applied ( https://cairographics.org/manual/cairo-Transformations.html#cairo-rotate https://cairographics.org/manual/cairo-Transformations.html#... ) before rendering. Otherwise you will see weird pixelation effects.
  - nostrademons 10y ago
    Information comes directly from the Chrome graphics team: https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome https://www.chromium.org/developers/design-documents/gpu-acc... (I actually spoke with them personally about this while I was still at Google, but there's the design doc. It's been 2 years, so perhaps the internals have changed, but this was also the situation in WebKit at the time as well.) And you do see weird pixelation effects - try rendering some text to a div and then animating 'transform: scale()'. You lose font antialiasing during the animation, which is why many sites that do this will fade out the text first, animate only the bounding box, and then fade the text back in.
    - 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.
- swah 10y ago
  Phones and "PCs" alike?
  - creshal 10y ago
    Yes, phones have reasonably fast GPUs for these usecases.
clevernickname 10y ago
Arbitrary gradients are trivial with pixel shaders.
zeta0134 10y ago
That's only true if you restrict yourself to vertex colors and shading. Every modern GPU supports fragment / pixel level shading, and can perform arbitrary gradients quite efficiently using this method.

by c-smile 10y ago

nostrademons 10y ago

For animations that touch only primitive transformations (scale/translation/rotation/opacity), the browser will usually render the element once on CPU, upload it to the GPU as a texture, and then composite it with the rest of the page on the GPU. That makes things like the spinning BB-8 or the blinking NO VACANCY basically free on the CPU.

c-smile 10y ago
I believe you are wrong. Usually browsers render all primitives as they are but with transformations applied ( https://cairographics.org/manual/cairo-Transformations.html#cairo-rotate https://cairographics.org/manual/cairo-Transformations.html#... ) before rendering. Otherwise you will see weird pixelation effects.
- nostrademons 10y ago
  Information comes directly from the Chrome graphics team: https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome https://www.chromium.org/developers/design-documents/gpu-acc... (I actually spoke with them personally about this while I was still at Google, but there's the design doc. It's been 2 years, so perhaps the internals have changed, but this was also the situation in WebKit at the time as well.) And you do see weird pixelation effects - try rendering some text to a div and then animating 'transform: scale()'. You lose font antialiasing during the animation, which is why many sites that do this will fade out the text first, animate only the bounding box, and then fade the text back in.
  - 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.
swah 10y ago
Phones and "PCs" alike?
- creshal 10y ago
  Yes, phones have reasonably fast GPUs for these usecases.

clevernickname 10y ago

Arbitrary gradients are trivial with pixel shaders.

zeta0134 10y ago

That's only true if you restrict yourself to vertex colors and shading. Every modern GPU supports fragment / pixel level shading, and can perform arbitrary gradients quite efficiently using this method.