Come on. It's thanks to articles like these I can finally have LLM write all those bullshit CSS hacks for me, and I even get to keep rejecting its commits until it gets it right!
(Though honestly, right now, getting GPT-4o to do responsive layout is an exercise in frustration equivalent to doing it myself.)
> However, using a transparent color significantly slowed down the number that can be drawn too which doesn't make as much sense to me. I'd imagine that with hardware today transparency should be somewhat free.
That's because transparency limits how you can batch draws on the GPU. With opaque draws, you can use the depth buffer and draw in any order you like e.g. maximizing batching. With transparency, you need to draw things in the right order for blending to work (painters order).
Yeah, somehow between comments I forgot this was about shadows and I was thinking more about drawing polygons. In that case, you can break up the polygons and work out the colors for each of the (theoretically 2^N) regions of overlap.
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.
My big take away with the whole City Skylines 2 performance issue and the lack of LOD was that geometry processing is so cheap nowadays. So long as you aren't too reckless with geometry in terms of sub-pixel rendering, you don't really have to worry about it too much any more.
It isn't like the Ps2 era when geometry time was a real concern on render times. Even a modern low end GPU could process a few hundred million polygons a second without sweating it, now getting the result son screen is a very different issue.
Yeah, PS2's Graphics Synthesizer had a fill rate of 1.2 GB/s. For comparison, the OG Xbox had 0.932 GB/s, and the GameCube had 0.648GB/s. Assuming only 1 texture here.
The Xbox was released 1 year later, for context.
Sony also demo'd the GSCube once, it had 16 Graphics Synthesizers, achieving a fill rate of 37.7 GB/s (no textures, half that with 1... I think). Eventually they ditched the idea in favour of Nvidia's solution.
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.
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
The tricky part is if you have faces that overlap in a cycle (can happen legitimately), or that penetrate each other (often avoidable if you think about it).
The game engines I've dealt with separate opaque and transparent geometry.
It is generally good to render opaque geometry back to front to reduce overdraw, but not going so far as sorting the objects. We would do stuff like render the hands first in an FPS or render the skybox last in most games.
Now for the transparent layer: First occlusion is handled by the z-buffer as usual. If you render from front to back I assume you render to another buffer first and then composite to the framebuffer? If you render from back to front you don't need alpha in your framebuffer and can assume each rendered pixel is opaque, not needing that composite.
There's also order independent transparency stuff though which IIRC does need another buffer, which requires a composite but then saves you having to sort the objects.
I could be wrong, but I remember folks that worked on Dreamcast games that loved how you could just throw the geometry at it in any old fashion you liked and the GPU would just sort it all out as needed. Transparencies and all.
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.
I think the above was a simplification. GUI rendering is a good example of jack of all trades, master of none. It doesn't use tight render loops like game engines but it much more flexible in terms of UI possibilities.
There is also the issue that GPU's are oddly terrible at generating 2D elements of which a desktop has thousands of them. There are things like Glyph caching but they can only go so far.
Having the CPU doing the majority of the work with a few rasterization tasks to the GPU makes sense.
> There is also the issue that GPU's are oddly terrible at generating 2D elements
I never knew this and honestly I’m a bit baffled - 2D seems simpler on its face, is it just that GPUs have been made with gaming in mind (typically) and most “hardcore gamers” are playing 3D games?
I can't find it right now, but I recall reading an article years ago where a newer, more powerful generation of GPUs turned out to have much less hardware for 2D operations/calls, and a fraction of the 2D performance, but the performance in 3D games went up so nobody really noticed.
Games are expected to have sole access to your machine, so if they use all the CPU/GPU resources, nobody cares. If my web browser was burning up my battery re-rendering the page 90 times a second, I'd be livid.
I think “consumes too much resources” is a valid concern. But I think “could cause lag because too many objects” is totally bogus. Rendering a web page isn’t that complicated.
I wouldn’t have thought so either, and then I learned the order in which CSS rules are applied and I’m convinced browsers have some of the most complex rendering engines out there.
> Games are expected to have sole access to your machine, so if they use all the CPU/GPU resources, nobody cares. If my web browser was burning up my battery re-rendering the page 90 times a second, I'd be livid.
Games 20 years ago had sole access to machines that were much less powerful than even partial access to today's machines.
And eg Nintendo Switch games (or games on the Steam deck, or just mobile phone games) still deal with power limitations; people are very aware when their games burn through their batteries.
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.
> It also turns out that some smart people figured out maths hacks to draw rounded boxes for super cheap which UI peeps love because with this hack boxes can be so round as to appear as circles
I'm totally down for some good old fashioned impractical hacking. But just remember, we already have canvas, which can do all this easier, faster, and better.
Canvas would still be faster even if you used a full-screen box. Just the string concatenation overhead of doing this with box-shadows is insanely wasteful.
Which isn't to demerit the hackish creativity of taking one thing and running with it! But if you wanted to do a ball painting effect like that outside this "what if" context, it would be technically irresponsible to do it with box-shadows.
For the past 30 years I got good at programming but never really did graphics because I didn't like games. I now view it as a massive oversight and have been trying to catch up for over a year.
Well, games are seen as fun, so they can attract programmers even with low salaries.
Basically the same reason pet veterinaries and teachers and nurses and musicians and artists still attract plenty of candidates despite a comparatively low pay.
(Playing games is more fun than working with CRUD apps. But writing games and writing CRUD apps seem about equal in their probability distributions of fun.)
Most of this is about the not-so-much-anymore-exotic art of GPU programming. It's becoming important in so many fields. The last thing I want to be is some foot-dragging old windbag who forgot to stay up to date.
As long as you get the job done within the estimates and make the client happy you're meeting your employment or job obligations. There is a lot of high paying salaries where people still parse csv jobs, and perform manual reporting with excel files.
This may sound laughable but I'm only in technology to build the future, I don't actually care about the money. Despite the current trend of tech pessimism, I still believe in tomorrow.
Gramsci's pessimism of the intellect, optimism of the will can be a tough motivator but I'm trying.
Are you building your future? I'm 41, and there are probably other users here who're older than me how-ever I was told when I was 16 that ftp/smtp/csv/https/oracle/database are legacy technologies but every day its my bread a butter. Technologies will come and go but your time is more important than trying to build for the future.
Just recently one of our security experts dropped dead over the weekend. When everyone heard about it they were sad for about 5 minutes, then 5 minutes later everyone was talking about their kids, parents, family, vacations or what they're going to have for lunch.
I don't mean that to be condescending, your life is important to you. Build your future, technology will take care of itself.
A great, possibly the greatest article I read this year ended with "your welcome" instead of "you're". Fix asap! Or maybe I didn't get the joke, that's a possibility
129 comments
[ 3.0 ms ] story [ 231 ms ] thread(Though honestly, right now, getting GPT-4o to do responsive layout is an exercise in frustration equivalent to doing it myself.)
> Layering. That is an important word.
Layering is also the key to the (silly but also sometimes good-looking) effects from my text shadow project from 14yrs ago: https://paulirish.github.io/mothereffingtextshadow/
Switched to Chrome - suddenly everything is butter smooth.
Congrats on an article very well done!
It's almost like this post has many layers to it, and that it's not really about box shadows.
For me it's not that it's freezing, it's that the page scroll stops responding.
I can get the tab back by cutting the URL, closing the tab, opening a new tab, pasting the URL, then scrolling to where I want to keep reading from.
It seems to render everything fine if you don't mind scroll stopping (ahem).
That's because transparency limits how you can batch draws on the GPU. With opaque draws, you can use the depth buffer and draw in any order you like e.g. maximizing batching. With transparency, you need to draw things in the right order for blending to work (painters order).
It isn't like the Ps2 era when geometry time was a real concern on render times. Even a modern low end GPU could process a few hundred million polygons a second without sweating it, now getting the result son screen is a very different issue.
The Xbox was released 1 year later, for context.
Sony also demo'd the GSCube once, it had 16 Graphics Synthesizers, achieving a fill rate of 37.7 GB/s (no textures, half that with 1... I think). Eventually they ditched the idea in favour of Nvidia's solution.
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.
It is generally good to render opaque geometry back to front to reduce overdraw, but not going so far as sorting the objects. We would do stuff like render the hands first in an FPS or render the skybox last in most games.
Now for the transparent layer: First occlusion is handled by the z-buffer as usual. If you render from front to back I assume you render to another buffer first and then composite to the framebuffer? If you render from back to front you don't need alpha in your framebuffer and can assume each rendered pixel is opaque, not needing that composite.
There's also order independent transparency stuff though which IIRC does need another buffer, which requires a composite but then saves you having to sort the objects.
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.
Games draw every single object on the screen every frame. They don't lag, quite the opposite in fact!
Not sure where that went in the end.
There is also the issue that GPU's are oddly terrible at generating 2D elements of which a desktop has thousands of them. There are things like Glyph caching but they can only go so far.
Having the CPU doing the majority of the work with a few rasterization tasks to the GPU makes sense.
I never knew this and honestly I’m a bit baffled - 2D seems simpler on its face, is it just that GPUs have been made with gaming in mind (typically) and most “hardcore gamers” are playing 3D games?
Games 20 years ago had sole access to machines that were much less powerful than even partial access to today's machines.
And eg Nintendo Switch games (or games on the Steam deck, or just mobile phone games) still deal with power limitations; people are very aware when their games burn through their batteries.
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.
Any references to learn more about these hacks?
A modern 3D accelerated article (using SDF as another commenter suspected) https://mortoray.com/quickly-drawing-a-rounded-rectangle-wit...
Have to add work by Evan Wallace here too as he is a legend.
https://madebyevan.com/shaders/fast-rounded-rectangle-shadow... https://madebyevan.com/webgl-path-tracing/
Which isn't to demerit the hackish creativity of taking one thing and running with it! But if you wanted to do a ball painting effect like that outside this "what if" context, it would be technically irresponsible to do it with box-shadows.
So hard.
Basically the same reason pet veterinaries and teachers and nurses and musicians and artists still attract plenty of candidates despite a comparatively low pay.
(Playing games is more fun than working with CRUD apps. But writing games and writing CRUD apps seem about equal in their probability distributions of fun.)
Gramsci's pessimism of the intellect, optimism of the will can be a tough motivator but I'm trying.
Not mocking, it's a tough ambition at times.
Just recently one of our security experts dropped dead over the weekend. When everyone heard about it they were sad for about 5 minutes, then 5 minutes later everyone was talking about their kids, parents, family, vacations or what they're going to have for lunch.
I don't mean that to be condescending, your life is important to you. Build your future, technology will take care of itself.