I don't think it's possible to partially decode/render a PNG in a way similar to JPEG. The only exception I can think of is adam7 interlacing, which _does_ store the initial pass as 8x8 blocks, but I'm pretty sure PNGs with adam7 are rare in practice because they do result in larger files.
reply> We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
replyWhat do you mean by "named the same" here?
deleted
replyits not possible to do this for pngs. Most likely though chrome is just using a quicker downscaling algorithm than your graphics editor is using (or just the wrong one. There is no universally correct algorithm, different ones work better for different image types).
replyHave you tried adjusting the image-rendering css property.
Ah this is weird! My understanding is that png doesn't store the images like jpg at all, they use a palette of all the colors in the image. Then each pixel is a reference to this palette. So it's not IDCT scaling, but I imagine there are other tricks to save on space/cpu when decoding pngs.
replyPNG supports both, palette based (for 8 bit and less), and just straight direct/true color (RGB or ARGB).
reply(still different from JPEG's method, of course)
You were using bitmap icons that were more than 8x larger on each axis than necessary? Why?
replyGuess: same icon used in very small size for lists/menus and much larger when you select the item. Also, if the same one is used for all resolutions, the actual size can vary widely between monitor sizes, DPIs, resolutions, scales. Good to have one that looks decent to people who see it large and/or care about quality
reply