Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So you think you know box shadows?

dgerrells.com

Post reply on HN
Print view View original

61–70 of 130 posts

Re: So you think you know box shadows?

#64

Post by tkzed49 »

klysm wrote: post #42
recursive wrote: post #37

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 throws away a lot though, especially w accessibility

now I'm imagining a screen reader reading off the coordinates of 1000 box shadows

Re: So you think you know box shadows?

#67

Post by krsdcbl »

ctippett wrote: post #20

I'm embarrassed to admit it took until the final paragraph before realising that 'gypity' is a reference to Chat GPT.

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

Re: So you think you know box shadows?

#68

Post by mabster »

o11c wrote: post #59
sunnyps wrote: post #23

> 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 dr…

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 re…

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.

Re: So you think you know box shadows?

#69

Post by breck »

paulirish wrote: post #8

Seriously fun exploration. > 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/

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

Post reply on HN