Hacker News Reader

Comment by derefr | Hacker News Reader

The thing I'm always surprised about with these sort of CSS hacks: they don't lag my browser. Like, at all. Even the animated ones! Which is really surprising when you compare them to literally any other way these illustrations could have been created. A sufficient mess of procedural Javascript to render the same designs would lag horribly. The equivalent Flash would make the browser choppy as all hell. As would a Java applet, if those were even still around. (SVG might not, but for the SVG to animate you'd need to use... CSS.)

Is CSS effectively "free", or is this just not a complex-enough example to start to see problems?

View on HN

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

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.

I believe you are wrong. Usually browsers render all primitives as they are but with transformations applied ( https://cairographics.org/manual/cairo-Transformations.html#... ) before rendering. Otherwise you will see weird pixelation effects.

Information comes directly from the Chrome graphics team:

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.

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

As you see the rendering is made in vector form, not as a bitmap rotation.

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

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

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.

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/

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.

> where I suspect it's walking the whole JSFiddle DOM to find out nothing has changed

No browser does this.

Phones and "PCs" alike?

Yes, phones have reasonably fast GPUs for these usecases.

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.

Arbitrary gradients are trivial with pixel shaders.

Here's an example of where CSS starts to become a bit more expensive:

http://www.keithclark.co.uk/labs/css-fps/nojs/

Edit: The site seems to be overloaded. Here's an archive:

https://web.archive.org/web/20160702222211/http://keithclark...

That was cool.

For me, it doesn't run well on FF, but neatly in Chrome. Huge difference.

Safari has lower than 1% CPU Usage when running it.

Beautiful! Runs exceptionally smooth using Chrome on an iPad Air 2. I have no doubt the GPU is doing most of the work. Less smooth on the same device using Safari.

It ran pretty well in Chrome Beta on my phone (~30fps?) for 10 seconds until the browser crashed.

Impressive.

I definitely had performance issues when I tried taking CSS hacks to the extreme: http://vitamintk.github.io/One-div-pics/

Renders fine on a $99 Windows phone. Crashes the browser on my iPad. The world is a funny place.

That's a software difference, software doesn't care bow.much your hardware costs.

I suspect my iPad crashes (all the damned time) because it's running a couple dozen services that take up all the RAM. Not that the Windows phone isn't, but it seems to manage them a bit better.

For the record: No crash on an iPad mini 2 (iOS 10 beta) and an ancient old iPhone 4S (iOS 9.3.1). The picture though is not rendered perfectly but has some white lines in it.

I was using Chrome on an iPad mini 1, and it crashed after I zoomed.

Please make the "don´t try to inspect this"-warning bold or bigger. I... well... I tried to inspect it...

So did I...

That was the last place i was expecting to see rtz today.

I like your baby(rage) sized example.

The days of yore when hand-crafted artisinal JavaScript could demand a kings ransom is well and truly behind us. Today the linear-gradient() smiths wield their spacetime-hammers in the octarine glow of quietly exploding minds.

What a time to be alive.

this is poetry

I could imagine it has to do with the fact that CSS is declarative and exposes a lot less "internals" to the user than JS does. This allows browsers to do a whole lot of optimisations (parallel execution, culling, delegation to GPU) without risk of breaking anything. With JS on the other hand, browsers must be careful to keep up the illusion of sequential, single-threaded execution because that's what JS code assumes.

> for the SVG to animate you'd need to use... CSS.

Not strictly true; it's also possible to animate SVGs using ECMAScript or SMIL: https://www.w3.org/TR/SVG/animate.html

> SVG might not, but for the SVG to animate you'd need to use... CSS

The difference is SVG + CSS is a better abstraction for creating illustrations than crazy CSS gradient and box shadow hacks.

It's not really comparable to JS animations, because the browser can render once and cache the pixels.

> The thing I'm always surprised about with these sort of CSS hacks: they don't lag my browser. Like, at all.

That would depend on your browser. Because AFAIK there is nothing in the CSS spec that guarantees any minimum performance.

So don't count on it being fast!

transitions and animation still run pretty bad on mobile browsers.

I would compare it like this: C is extremely fast php which is built on C is not so fast So css is like C, built on the internal stuff so pretty much no overhead or anything. Javascript animations are like php, built on top of css with just manipulation of the css/dom structure.

What you mean the say is "there are less abstraction layers".

Reply on news.ycombinator.com