I have been installing LibreOffice on a fresh Windows 11 PC and found that the default selected icon theme caused the menu bar icons to be pixelated. Trying to find out why, I stumbled across this entry: https://ask.libreoffice.org/t/tool-bar-icon-appearance-blocky-can-it-be-fixed/45468 Describing that it can be fixed by switching the Theme to an SVG based one. Did that - worked (fixed things) for me. So I am wondering - why is SVG based not the default anyway. Looking at this tracker, I found at least one issue with SVG themes. Nevertheless, there is obviously also issues with non-SVG. And as SVG conceptually would be a better choice for "always works in any resolution/screen/scaling situation", I wanted to ask if SVG could be a sensible default setting for the future. In the end, a neat (or crappy) UI is the first thing any user sees after installtion. It is the first impression. It should be as neat as possible.
No, the reason we don't convert from SVG at default 100-125% os/DE theme is that the SVG --> PNG conversion is lossy at those scales. Converted PNG can not match the precision and crispness that an icon designer achieves in bitmap at that scaling range. So comparing the two the converted SVG appear fuzzy, just as bad as pixilation at the higher scaling. Otherwise, for performance we don't directly render the SVG icon themes on the UI, we convert them into PNG and display those. So we deliver the prebuilt PNG (16px, 24px, 32px) to support the vast majority of users cross platform, with ability in UI to select an SVG icon theme. The SVG are delivered with the installation, placed to the share/config folder. So on selecting the SVG icon theme it generates a PNG rendering of the theme based on the scaling factor and writes it to user profile (%APPDATA%\LibreOffice\4\cache folder per theme at each scale factor). It is only with scaling on HiDPI devices, or use of larger display panel formats that pixilation of the icon themes becomes noticeable. Though recently for macOS we shifted to use the SVG icon theme directly, but that is more in line with macOS display norms and its native source. Not applicable to other os/DE.
*** This bug has been marked as a duplicate of bug 150973 ***