A Broken Heart
allenpike.com
A Broken Heart
1–10 of 53 posts
Re: A Broken Heart
#2[flagged]
Re: A Broken Heart
#3This is a legitimately fun piece about a bug (or extraordinary levels of inefficiency) in CoreSVG, manifested in massive computational loads to display a single SVG fallback for a colour-specified emoji.
But, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is overkill if you really wanted to do something crazy with an emoji or text, and it seems to focus on gradients and the like.
Maybe this is why they humorously blame Claude for getting them to use that font and its affordances in the first place.
Re: A Broken Heart
#4[deleted]
Re: A Broken Heart
#5This is a legitimately fun piece about a bug (or extraordinary levels of inefficiency) in CoreSVG, manifested in massive computational loads to display a single SVG fallback for a colour-specified emoji. But, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is o…
As a bit more on this, until this piece I was oblivious to this COLRv1 thing, which is adding more of SVG-style functionality to already vector font standards.
https://developer.chrome.com/blog/colrv1-fonts
My natural cynicism is to ask "should a font really do this?" But I guess it's pretty neat.
Re: A Broken Heart
#6The conclusion of "yes, Claude helped fix this, but it also caused it by recommending an emoji font" seems a bit disingenuous to me. Using an emoji font is a good suggestion, it's not like Claude (or anyone) could have known there's an SVG but that will cause this slowness.
Re: A Broken Heart
#7This is a legitimately fun piece about a bug (or extraordinary levels of inefficiency) in CoreSVG, manifested in massive computational loads to display a single SVG fallback for a colour-specified emoji. But, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is o…
It's not solid red. It has shading.
Re: A Broken Heart
#8... and a broken world.
How infuriating it is to see complexity so spuriously piled up upon an already holy mess.
Re: A Broken Heart
#9This is a legitimately fun piece about a bug (or extraordinary levels of inefficiency) in CoreSVG, manifested in massive computational loads to display a single SVG fallback for a colour-specified emoji. But, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is o…
It's not solid red. It has shading.
I don't think the blog post itself is using that emoji font. The screenshot on the Noto Emoji Github page[0] doesn't look like it's using any gradients for the heart emoji, just flat shading. But it is using gradients for some of the other emojis (e.g. the croissant), and obviously the SVG fallback is all or nothing, not per-glyph.
Re: A Broken Heart
#10Maybe off topic, but I couldn't help thinking that "we need to show a heart icon" -> "let's use a heart emoji because it's easy" -> "let's use a specific emoji font for consistency across platforms" -> "let's import it from Google Fonts every time" seems like a problematic developer mindset.
A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize everything, but keep program efficiency in mind at least a little bit. In this case, that would've led the developer to download a tiny SVG or PNG and serve it from the app itself. Which would've avoided the problem in the post, and maybe other problems as well.