[HN Gopher] So you think you know box shadows?
___________________________________________________________________
So you think you know box shadows?
Author : yohannesk
Score : 421 points
Date : 2024-07-21 12:38 UTC (10 hours ago)
(HTM) web link (dgerrells.com)
(TXT) w3m dump (dgerrells.com)
| paulirish wrote:
| 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/
| rustystump wrote:
| <3
| cchance wrote:
| He said it might melt your processor... but on a macbook m3 in
| arc runs great, like every one of those was amazing.
| chuckadams wrote:
| It's butter on my M1 Air too, in Chrome and Firefox.
| Surprisingly, it's a slideshow on Safari.
| dahart wrote:
| On Safari iPad, I lose the ability to scroll or do anything
| somewhere in the middle of the article.
| labster wrote:
| Huh, I read the whole article and interacted with all the
| inline examples on my iPhone SE/2.
| tux3 wrote:
| Even on a 7 year old first gen AMD, it's smooth as butter.
| Looks like Stylo and Webrender doing a great job?
| magnio wrote:
| Maybe the author tests it on some old device with outdated
| graphics driver, because they all run smoothly on my 5 yo
| Android.
| tetris11 wrote:
| Chiming in with my Samsung J3 2016, it ran pretty well here
| too
| layer8 wrote:
| M4 iPad Pro here started to freeze up on the Starry Night
| animation.
| qingcharles wrote:
| Weird. I'm on a 2011 Lenovo desktop with an i5 and it ran
| smooth as butter.
| layer8 wrote:
| Probably Safari is at fault.
| jimmaswell wrote:
| All the examples were good on my Samsung S22 Ultra too, really
| cool.
| sweca wrote:
| Worked very well on my Pixel 7 in Chrome too
| callwhendone wrote:
| M1 Pro here and it ran completely fine.
| llama_drama wrote:
| That's weird because it completely freezes m2 ipad
| mavamaarten wrote:
| I ran it on my Pixel 7A and even the ray tracing demos ran
| insanely quickly. I seriously did not expect that.
| sorrythanks wrote:
| Firefox on an m2 has taken the news of these bouncing balls
| extremely poorly
| adrianpluis wrote:
| Well done with writing your experience.
| ctippett wrote:
| I'm embarrassed to admit it took until the final paragraph before
| realising that 'gypity' is a reference to Chat GPT.
| noqc wrote:
| I took until here.
| fitsumbelay wrote:
| same
| p0seidon wrote:
| same
| zarathustreal wrote:
| Hmm.. I must be even further out of the loop than you, why
| would that be embarrassing?
| jbritton wrote:
| Primeagen YouTube channel lingo.
| krsdcbl wrote:
| 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
| sunnyps wrote:
| > 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).
| amelius wrote:
| Can't you mathematically work out how to change the
| colors/opacity to rearrange the job?
| Rapzid wrote:
| Having that knowledge sounds just as expensive if the
| operations aren't commutative.
| amelius wrote:
| 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.
| klysm wrote:
| I think there's still a dependency graph
| Cloudef wrote:
| 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.
| delusional wrote:
| 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.
| o11c wrote:
| Reverse-painter's-order beats painter's-order since it lets you
| skip fully-occluded objects: Start with a
| buffer that's fully transparent (a=0.0) for each face
| from front to back: for each pixel of the face:
| draw the pixel, blending 1.0-buffer.a of the new pixel into
| whatever's already in the buffer (if buffer.a == 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).
| mabster wrote:
| 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.
| yesimahuman wrote:
| > 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
|
| Any references to learn more about these hacks?
| pmhpereira wrote:
| Probably signed distance fields (SDF).
| leecommamichael wrote:
| 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...
| rustystump wrote:
| I was thinking SDFs and the Bill stuff at time of writing.
| Read my mind.
|
| 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/
| recursive wrote:
| 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.
| egypturnash wrote:
| But with less comedic value. Doing this with nothing but box-
| shadow is _funny_ , mostly _because_ it is so impractical.
| klysm wrote:
| Canvas throws away a lot though, especially w accessibility
| recursive wrote:
| Really? I would have guessed that canvas provides pretty much
| exactly the same accessibility as a UI rendered entirely out
| of box shadows.
| tkzed49 wrote:
| now I'm imagining a screen reader reading off the coordinates
| of 1000 box shadows
| butz wrote:
| But at the end of the day Firefox and Chrome are still rendering
| 1px box-shadow differently at 150% browser zoom. Best hopes for
| Baseline 2025.
| ulf-77723 wrote:
| Really great work, especially the music synced animation - could
| as well also be projected in an electro club
| winrid wrote:
| This discussion around adding shadows to window boarders in imgui
| is also interesting: https://github.com/ocornut/imgui/issues/1329
| nimish wrote:
| Full color RGB flip dot display!
| develatio wrote:
| dgerrells, please add RSS support to your blog!
| rustystump wrote:
| Done. Let me know if it works.
| kristopolous wrote:
| 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.
|
| So hard.
| fitsumbelay wrote:
| My kind of hackin' Almost like an antichrist to the Josh Comeau
| posts I've read on the topic
| https://www.google.com/search?q=josh+comeau+shadows
| pfannkuchen wrote:
| Solid watch for rolling rocks energy.
___________________________________________________________________
(page generated 2024-07-21 23:00 UTC)