PNG vs. SVG icons

[cubiclesoft]

Currently, the icons in the widget are sourced from a single PNG sprite sheet. The switch to PNGs was done after attempting a SVG icon implementation that rendered rather badly on desktop browsers.

Unfortunately, devices with higher pixel densities scale up the PNG icons, which ends up looking blurry. This was discovered pretty late during development.

The quick fix was to apply the relatively new CSS image-rendering: pixelated feature to provide a hint to the scaler to increase the crispness of the images. However, there are now a few jaggy edges and supposedly mobile Safari (iOS) flips the meaning of pixelated vs. crisp-edges. I would prefer a more refined option like "edge-detect-pixelated" that combines nearest neighbor for the interior and smooths out the edges of the scaled image instead of blunt instruments like nearest neighbor vs. bicubic scaling.

Overall, this is a minor issue. If someone wants to tackle it, be my guest. All the artwork used to create the widget is in the 'artwork' directory. Desktop browsers are the most critical environment, which means there can't be odd visual artifacts that show up on desktop browsers. SVGs tend to not display consistently at small sizes across browsers.

[webketje]

It's really bad on a standard FHD 1920x1080

FWIW I don't think this is still a valid negative in current browsers for inline SVGs:

SVGs tend to not display consistently at small sizes across browsers.

[cubiclesoft]

Why is the text so huge in your screenshot? Using in-browser zoom causes all kinds of artifacting in general - not just this widget.

And SVGs most definitely do not display consistently at small sizes across browsers. That is a known problem with SVG renderers. SVGs aren't really all that suitable for small icons anyway.

[webketje]

I didn't use in-browser zoom for the screenshot. Turns out the Windows scaling feature is the culprit:

Notice how the recommended option is 150%. Small PNGs become problematic if Windows auto-adjusts its 'recommended' zoom according to the screen's physical size. And if you search online, there are actually quite some reports about Windows 11 doing just that.

SVG has been a standard inclusion in front-end frameworks for icons for a long time now (including for ex. FontAwesome & Material UI icons) so maintaining that SVGs aren't really all that suitable for small icons flies in the face of the entire industry's direction. If resistant to replacing the PNG sprite, another option would be to increase its size to n * 1.5 or n * 2 combined with background-size. Downscaling definitely better than upscaling.

Even better would be to have an iconsPath option provided to window.FileExplorer, this way one could replace the very "Windows-y" look of the icons by something else completely

[cubiclesoft]

No need for an iconsPath option. Just override the relevant styles in the CSS with your own website stylesheet rules.

The switch to PNGs was done after attempting a SVG icon implementation that rendered rather badly on desktop browsers.

That original comment still stands. I attempted to use SVG, it didn't work well, and so ended up using PNG. The situation hasn't changed any in the last 4 years nor is likely to ever change. It is well known that complex SVG does not scale down well and also well known that raster images like PNG do not scale up well.

Font Awesome and Material icon styles are 1-2 colors with simple lines and shapes. That's why they work as SVGs but even they struggle to scale down to very small sizes (e.g. 12x12, 16x16). The icons here are more complex and have multiple colors. Granted, they are shown at 24x24, which is larger than 16x16 but, as I said earlier, SVG didn't work out and the icons looked terrible at 24x24. Anyone who has ever made small icons knows SVG is not a suitable format for small icons that have sufficient detail embedded into them. They have to be rasterized and then apply many pixel-level tweaks so that they look good. Making large PNG icons that scale smaller for normal displays is also a non-starter because you'll wind up with a blurry mess for similar reasons.

The real problem is that the PNG file format does not support storing multiple copies of the same image at different display densities. On the flip side of the same problem, SVG can't store raster image data that supports different display densities. A proper icon file format that scales to all sizes and display densities would use a combination of PNG and SVG and let the browser/OS make the best decision of what to display. The file format could even support things like storing multiple sprite images inside a single file. It's almost like there's a suitable use-case here for sanely supporting IFDS in image editors and web browsers instead of all the hackery that keeps happening:

https://github.com/cubiclesoft/ifds

Overall, this is a minor issue. If someone wants to tackle it, be my guest.

My original comment still applies. It's still a minor issue. You are welcome to submit a working fix for all major display densities.

The various icons are rendered using fixed pixel sizes and background-position on the sprite. As of 2022, a CSS media rule exists called resolution that all major browsers support. Prior to 2022, however, resolution wasn't fully supported everywhere. The existing sprite sheet + CSS embedded SVGs for higher display densities split up using a suitable resolution CSS media query is a possible solution.