That’s not how CSS box shadows are generated. They only need to take into account the dimensions of the rectangle and the corner radius, which opens up for a lot of optimization.

Take a look at the layer tree in the overflow menu in the chrome devtools. You can see which shadows had to be rendered to a buffer and which did not.

I suspect the complexity is that some objects can be transparent, and then their shadows get complex.

If you have an example of how transparency makes the shadow more complex, please give it. I’m fairly confident there are no cases like that. Transparency in the background image or border doesn’t change the shape of the box the shadow applies to, and things like opacity affects the shadow too. The example you had in your first comment is also wrong, as shadows don’t apply to other shadows.

There might still be cases where a particular optimization doesn’t work and the browser falls back to a buffer.

I agree that a benchmark on CPU/GPU would be helpful for this effect. However, I doubt you'd end up running out of ram through using this technique unless it was added to a large number of elements.

Makes me wish the css filter feature hadn't fizzled. Would be much more performant to do this in a single pass by giving a gradient to a box distance formula in a shader!

That will not generate a visually pleasing shadow, though.

Because? You could specify any formula you want. Including lookup tables. If you can describe it, the shader can render it.

Because a visually pleasing shadow does not follow a box distance function at all.