Hacker News Reader

Comment by randallu | Hacker News Reader

The "translateZ: 0" description is a bit misleading -- I wish he'd provided numbers for the improvement. In general using composited layers is more expensive (since the CPU still does rendering of the image, must upload it to texture, etc).

It might be a win if the thing you apply it to:

1. Never changes, but the content around it changes often.

2. Is hard to render (lots of shadows, etc).

The layout and paint thrashing is a really good optimization though. You should be able to insert as many things into the DOM as you like without triggering a layout SO long as you don't read back (like consulting offsetLeft). I think the Chrome inspector will mark read backs with a little exclamation point in the timeline with a tooltip "synchronous layout forced" and a backtrace to your JS...

View on HN

The translateZ deal just throws the browser into hardware rendering, which will run much smoother with any GFX hardware that will support it.

The same thing works with all of the other 3d transforms: Putting in a BS value for Z will cause the element to use hardware acceleration.

The translate z trick does not work in general. It works right now in Chrome (and probably Safari). It does not work in Firefox, it may not work in Chrome in the future. (Because you are trying to trick the browser by gaming it's heuristics, those heuristics might change).

That hardware rendering is smoother is also not true in general, just some cases, which the browser will try to guess for you.

You should be careful when adding translateZ. If you go beyond the GPU memory it's going to be extremely slow and has high chances of crashing the app.

How easy is that to do accidentally? 128MB is enough for 16 screenfulls at 1080p. Can you really trigger the creation of that many hardware-composited layers without intending to?

No, translateZ just makes it a composited layer. Hardware comes much later in the pipeline and possibly in another process.

The content of the layer isn't hardware rendered. It's rendered by the CPU and uploaded to a texture. In WebKit and probably Blink there's a fast path for images, canvas and video so that they can be directly uploaded or (on some platforms like Mac) bound to a texture avoiding an upload copy.

Microsoft and (maybe) Mozilla have a "hardware rendering" path via Direct2D, but Chrome and WebKit don't, they have compositors which can use the graphics hardware to perform compositing, but not rendering.

For what it's worth, WebKit on OS X uses hardware acceleration for both rendering and compositing by way of Core Animation.

Oh, nice! For some reason I thought that was only for canvas.

It was only used for canvas in the initial release before being deployed more widely.

Which technologies do benefit from GPU rendering? Aren't Quartz calls rasterized on CPU?

Core Animation layers have a mode in which Core Graphics calls targeting them are both processed asynchronously by a another thread and rasterized via OpenGL.

I presume you mean the "drawsAsynchronously" property. I'm extremely curious, does it really push the rasterization on the GPU? I mean, do you have shaders written, that do all the stuff that CPU normally does? Bezier paths, clipping, stroking, filling?

Reply on news.ycombinator.com