Hacker News new | ask | show | jobs
by adam_arthur 1527 days ago
Seems a lot more performant to generate single color images programatically rather than sending it over the wire?

Assuming this level of optimization is actually warranted

2 comments

I mean, you could. Not a browser author or map maker but thinking it out loud.

This would be a 'rectangle color' specific. Probably 24 bytes to represent height, width, color? It seems like a Herculean effort to attempt to get browser support for such a thing, for a phenomenally rare use case. It would need to be an image format probably and not a browser implementation, since they're usually arranged around other images. And all for saving some 60 bytes per square.

To be clear I'm not saying it's a bad idea - I'm all for it. It just seems like a pretty edge use case(large blobs of single color images such as oceans in cartoon maps).

People can and have written image decoders for custom formats in Javascript [1]. This seems like the same thing but for a very domain-specific use case.

Worth it? Not sure. But possible? Definitely.

[1]: https://bellard.org/bpg/

> It seems like a Herculean effort to attempt to get browser support for such a thing

https://caniuse.com/datauri

Data URIs have much more widespread utility than what is being discussed, I think.
fwiw, JPEG-XL manages to encode the whole image in only 22 bytes.
i thought so too, but is it actually the case? it's a bit more js code but if pack all your js files there's one less http header. then it's cached. for the image you got the initial size + header (roughly 500 bytes), then it's cached all the same. so, if the additional js gz'd is smaller than 100 bytes of png + gz(400 bytes for the header) it might pay off.