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

51–60 of 130 posts

Re: So you think you know box shadows?

#51

Post by recursive »

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

Really? I would have guessed that canvas provides pretty much exactly the same accessibility as a UI rendered entirely out of box shadows.

Re: So you think you know box shadows?

#56

Post by delusional »

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…

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.

Re: So you think you know box shadows?

#59

Post by o11c »

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 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).
Post reply on HN