So you think you know box shadows?

I think it's more complex than that. While web browsers do use GPU rendering, they're not game engines. They don't draw every single object on the screen every frame, that could easily cause lag on a large complex page.

Chromium in particular tries to minimize the total number of layers. It renders each layer into a pixel map, then for each frame it composites all of the visible layers into the final image.

That works really well in practice because you often have lots of layers that move around but don't actually change their pixels. So those don't need to be rendered (rasterized) every frame, just composited.

If you have a bunch of box shadows without transparency, Chromium will rasterize the whole thing once as a single layer.

If you have a bunch of box shadows with transparency, Chromium might create a separate layer for each one. That's probably suboptimal in this particular case, but imagine if your partially transparent box shadows had to also slide around the page independently.

Reverse-painter's-order beats painter's-order since it lets you skip fully-occluded objects:

  Start with a buffer that's fully transparent (α=0.0)
  for each face from front to back:
    for each pixel of the face:
      draw the pixel, blending 1.0-buffer.α of the new pixel into whatever's already in the buffer
      (if buffer.α == 1.0 you can just skip it entirely, just like for depth buffering)
  go back and double check your math relating to transparent objects behind other transparent objects

GPUs also do not like overdraw, so it's generally good idea to avoid having many transparent elements on top of each other, its also the reason why drawing more triangles vs. transparent texture is generally better.

The "Ordering" step doesn't really matter that much. You're usually doing a sort anyway prior to submitting the drawcall. What hurts is the overdraw. If you're doing opaque rendering, you get to render front to back, rendering only what actually appears on the final framebuffer. The number of pixels (after the depth pass) is proportional to the framebuffer. When you're doing transparent rendering you render back to front, and you have to render a tonne of the scene that will eventually be (partially) obscured by other random polys. We call that overdraw. The amount of pixels through the shader pipeline balloons to be proportional to the size of your mesh.

If you're doing non-overlapping stuff, you'd actually expect (almost) no slowdown from transparency, since you'd have to touch every pixel once anyway, and the only thing that changed is the shader formula.

One more thing to consider is memory bandwidth, which can be limiting factor especially on mobile devices.

A non-transparent draw over another draw allows in best case to cull all overlapping drawing operations, in worst case means you only have to use as much bandwidth as the individual draws.

With transparency, especially if you can't somehow combine the operations together (from my understanding, very hard problem), it means you also need to read back the entire region you're overlapping with transparency - so every transparent draw involves at least twice the final framebuffer size bitmap going-over memory bus.

Now consider that many mobile devices had not enough memory bandwidth to do a full redraw (i.e. blit the full framebuffer image twice) of the screen in time to maintain 60fps and it becomes a considerable problem.

Can't you mathematically work out how to change the colors/opacity to rearrange the job?

> Layering. That is an important word.

It's almost like this post has many layers to it, and that it's not really about box shadows.

<3

I took until here.

Primeagen YouTube channel lingo.

fun fact, this had me realise the term isn't some kind of in joke spawned of a colleague's mind, but actually a meme in the progess of becoming one

Chad Gipity is a good guy... ;-)

Same, I thought it was some sort of tool related to gyp but for client side.

Hmm.. I must be even further out of the loop than you, why would that be embarrassing?

But with less comedic value. Doing this with nothing but box-shadow is funny, mostly because it is so impractical.

Canvas throws away a lot though, especially w accessibility

Canvas is better...if you're trying to do something that stays within a fixed-size box.

Sure, and we already have keyboards, so there's no need to use floppy drives or rubber chickens to make music either.

Still use Winamp (actually WACUP) with Milkdrop visualizations almost every day. But true that streaming audio players are so basic featureless pieces of software.

Some historic articles on software rendering (the original Bill Atkinson stuff) https://www.folklore.org/Round_Rects_Are_Everywhere.html http://wg20.criticalcodestudies.com/index.php?p=/discussion/...

A modern 3D accelerated article (using SDF as another commenter suspected) https://mortoray.com/quickly-drawing-a-rounded-rectangle-wit...

Probably signed distance fields (SDF).

nothing to see here...

I did games first, then switched over to crud or simple oracle form programming. I tripled my original game programmer wage overnight.

Done. Let me know if it works.

I ran it on my Pixel 7A and even the ray tracing demos ran insanely quickly. I seriously did not expect that.

Maybe the author tests it on some old device with outdated graphics driver, because they all run smoothly on my 5 yo Android.

On Safari iPad, I lose the ability to scroll or do anything somewhere in the middle of the article.

It's butter on my M1 Air too, in Chrome and Firefox. Surprisingly, it's a slideshow on Safari.

M4 iPad Pro here started to freeze up on the Starry Night animation.

All the examples were good on my Samsung S22 Ultra too, really cool.

Even on a 7 year old first gen AMD, it's smooth as butter. Looks like Stylo and Webrender doing a great job?

Firefox on an m2 has taken the news of these bouncing balls extremely poorly

Worked very well on my Pixel 7 in Chrome too

M1 Pro here and it ran completely fine.

A lot. Please don't do this in production.