ximion
Ship icons in svg if available
It would be nice, to ship app icons as svg, if the app provides a scalable.
That way we're future proof and according to some blogs, we should also be able to save bandwidth with that.
https://vecta.io/blog/comparing-svg-and-png-file-sizes (there might be a bias in that blog, due to the tool they are pushing)
This was discussed a long time ago and vehemently rejected by @hughsie due to the rendering overhead that rendering that many SVGs in overviews incurs.
Back then I was in favour of having SVGs, because it would be a lot more space-efficient than shipping many PNG renders and people would stop asking for more and more sizes to be added. But since @hughsie maintained GNOME Software at the time and it's the store apps which need to do the rendering (and subsequently get bug reports if things are slow / power-hungry) I ultimately gave up on the idea.
Not sure what the status is now... I think the thing that would convince me is a clear yes from software center application developers. Then, adding a "scalable" option and shipping SVGZ files would be fine with me.
As things are now, I am looking forward to replacing the PNGs with JXL some time long in the future. The latter has quite significant space savings at the same quality, but support for JpegXL is very lacking. So, it's a "distant future" goal (as we will also only save space if we remove the PNGs).
@aleixpol @pwithnall can you give some feedback from software center po?
JPEGXL would be good, but won't solve the scale race problem. We started to already use webp for Screenshots on flathub.org
SVGs are great for solving the problem of scaling in terms of pixel density, but it doesn't solve scaling in terms of displaying icons at different logical sizes. An icon displayed at (for example) 32px in a list might have reduced detail and different proportions to be more legible at that small size compared to a 128px icon used in a banner. SVG means you don't need a 32px@2 and 32px@3, but it doesn't mean you won't have both a 32px and 128px image that have different contents
That's fair, but I'm not sure I've seen that used in the wild so far - which doesn't mean it does not exist.
That also kinda breaks the notion of one scalable folder then.
This was discussed a long time ago and vehemently rejected by @hughsie due to the rendering overhead that rendering that many SVGs in overviews incurs.
I wasn’t around at that time, so I don’t know the research/background/reasoning behind that. If it was true then, it’s probably still true now (I don’t know if librsvg has seen that much profiling).
This is not something I’m going to have time to sit down and profile in the near future.
I suggest you can decouple this from me blocking things, by going ahead and shipping SVGs in the metainfo (if you decide to do that). And then if that slows gnome-software down then we can later change gnome-software to ignore them. As long as PNGs don’t go away entirely we’ll be fine.
Can we at least get a flag, that copies svgs as they are to the target? Would be helpful for flathub (ignoring all native clients) at least.
Can we at least get a flag, that copies svgs as they are to the target? Would be helpful for flathub (ignoring all native clients) at least.
You mean, in addition to the rendered 64x64px bitmap icons?