3 ms·

I'm pretty sure the same issue happens with PNGs, which being lossless are generally good for icons as they don't land up with compression artifacts like what h

I'm pretty sure the same issue happens with PNGs, which being lossless are generally good for icons as they don't land up with compression artifacts like what happens in JPEGs (which the author points out are really for photographs), they also support alpha blending. When Chrome introduced this "optimization" and it made it through to an Electron release which we were upgrading to, it really messed up the icons in a lot of places in our product such that we had to hold off the upgrade until we had SVGs to replace them. SVGs also have the advantage of being able to respond to light/dark mode. 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.

StilesCrisis 2mo ago
You were using bitmap icons that were more than 8x larger on each axis than necessary? Why?
- aljgz 2mo ago
  Guess: 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
  - jonathanlydall 2mo ago
    Pretty much. The icon appeared bigger in some places than others and wanted it to look decent on higher DPI displays. SVGs are so much better for this though, smaller in size and look great at pretty much any resolution.
gutechh 2mo ago
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.
- binaryturtle 2mo ago
  PNG supports both, palette based (for 8 bit and less), and just straight direct/true color (RGB or ARGB). (still different from JPEG's method, of course)
polpo 2mo ago
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.
- jonathanlydall 2mo ago
  Perhaps it was a different optimisation, but it definitely made significantly downscaled PNGs look way worse under particular circumstances. It was especially noticeable on triangles we used on nodes of a tree view control.
  - bawolff 2mo ago
    Yeah, images with sharp contrasts like line art tend to do badly with the scaling algorithms that work well with photos. It is why browsers introduced `image-rendering: pixelated` css, but as you noted in the other comment, SVG is almost always the best answer.
jancsika 2mo ago
> 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. What do you mean by "named the same" here?
- jonathanlydall 2mo ago
  SVGs can define styles and element ids. The problem is if these same element ids and styles are used in different places in your DOM, including other SVGs. Our product is a bit of a platform with extensibility which includes icons for ui elements. It was very easy for us or our users to accidentally use the same style names or element ids when exporting from Adobe Illustrator, especially for icons which are similar to others and started as a copy. When using SVGs as a background it’s not an issue, but we want our SVGs to be able to have different colours be usable in light or dark mode which CSS can do, except it doesn’t work when making the SVG a background. Shadow DOM solves this issue perfectly.
  - jancsika 2mo ago
    Why not use classes instead of element ids?
    - jonathanlydall 2mo ago
      When I referred to “styles” I was referring to classes. If the same class was defined in a multiple SVGs under their respective <style/> elements, they would affect each other. So sometimes if two icons were in the DOM at the same time, the one’s colours might look wrong since both had the same class names they were using. Element ids were also not used so much for styling but instead for common SVG components (or something, I don’t know the terminology), so would similarly cause rendering issues. Like I said it was especially common if the one started as a copy of the other in Illustrator. The “fix” was to ensure unique element ids and class names, but this was an annoying extra step. Using a shadow DOM for each icon which is an SVG circumvents the entire problem as they ignore anything outside their isolated DOM.
bawolff 2mo ago
its 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). Have you tried adjusting the image-rendering css property?
- jonathanlydall 2mo ago
  I can’t recall the details any more, but I recall seeing something like this in my research on the issue, it might have been a solution to the issue, or I was worried it had a noticeable performance impact. We may also have moved to the SVGs anyway as they also look much nicer when running at different zoom levels like 125%.
deleted 2mo ago
[deleted]
RunSet 2mo ago
Chrome puts artifacts in its canvas when you draw text and Firefox does not. Makes bitmap fonts ugly. https://stackoverflow.com/questions/47139528/html5-canvas-text-anti-aliases-in-chrome-not-in-firefox https://stackoverflow.com/questions/47139528/html5-canvas-te... My inner paranoiac says it is something like yellow dots[0] for browsers but it could just be negligent developers. [0] https://en.wikipedia.org/wiki/Printer_tracking_dots https://en.wikipedia.org/wiki/Printer_tracking_dots

StilesCrisis 2mo ago

You were using bitmap icons that were more than 8x larger on each axis than necessary? Why?

aljgz 2mo ago
Guess: 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
- jonathanlydall 2mo ago
  Pretty much. The icon appeared bigger in some places than others and wanted it to look decent on higher DPI displays. SVGs are so much better for this though, smaller in size and look great at pretty much any resolution.

gutechh 2mo ago

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.

binaryturtle 2mo ago
PNG supports both, palette based (for 8 bit and less), and just straight direct/true color (RGB or ARGB). (still different from JPEG's method, of course)

polpo 2mo ago

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.

jonathanlydall 2mo ago
Perhaps it was a different optimisation, but it definitely made significantly downscaled PNGs look way worse under particular circumstances. It was especially noticeable on triangles we used on nodes of a tree view control.
- bawolff 2mo ago
  Yeah, images with sharp contrasts like line art tend to do badly with the scaling algorithms that work well with photos. It is why browsers introduced `image-rendering: pixelated` css, but as you noted in the other comment, SVG is almost always the best answer.

jancsika 2mo ago

> 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. What do you mean by "named the same" here?

jonathanlydall 2mo ago
SVGs can define styles and element ids. The problem is if these same element ids and styles are used in different places in your DOM, including other SVGs. Our product is a bit of a platform with extensibility which includes icons for ui elements. It was very easy for us or our users to accidentally use the same style names or element ids when exporting from Adobe Illustrator, especially for icons which are similar to others and started as a copy. When using SVGs as a background it’s not an issue, but we want our SVGs to be able to have different colours be usable in light or dark mode which CSS can do, except it doesn’t work when making the SVG a background. Shadow DOM solves this issue perfectly.
- jancsika 2mo ago
  Why not use classes instead of element ids?
  - jonathanlydall 2mo ago
    When I referred to “styles” I was referring to classes. If the same class was defined in a multiple SVGs under their respective <style/> elements, they would affect each other. So sometimes if two icons were in the DOM at the same time, the one’s colours might look wrong since both had the same class names they were using. Element ids were also not used so much for styling but instead for common SVG components (or something, I don’t know the terminology), so would similarly cause rendering issues. Like I said it was especially common if the one started as a copy of the other in Illustrator. The “fix” was to ensure unique element ids and class names, but this was an annoying extra step. Using a shadow DOM for each icon which is an SVG circumvents the entire problem as they ignore anything outside their isolated DOM.

bawolff 2mo ago

its 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). Have you tried adjusting the image-rendering css property?

jonathanlydall 2mo ago
I can’t recall the details any more, but I recall seeing something like this in my research on the issue, it might have been a solution to the issue, or I was worried it had a noticeable performance impact. We may also have moved to the SVGs anyway as they also look much nicer when running at different zoom levels like 125%.

deleted 2mo ago

[deleted]

RunSet 2mo ago

Chrome puts artifacts in its canvas when you draw text and Firefox does not. Makes bitmap fonts ugly. https://stackoverflow.com/questions/47139528/html5-canvas-text-anti-aliases-in-chrome-not-in-firefox https://stackoverflow.com/questions/47139528/html5-canvas-te... My inner paranoiac says it is something like yellow dots[0] for browsers but it could just be negligent developers. [0] https://en.wikipedia.org/wiki/Printer_tracking_dots https://en.wikipedia.org/wiki/Printer_tracking_dots