App icons are blurry with 200% scaling

[PhilippSua]

App icons are blurry with 200% scaling:

The icon used here (https://dl.flathub.org/media/org/gnome/gitlab.somas.Apostrophe/79e84cd62f433972088419e196bc13ff/icons/128x128/org.gnome.gitlab.somas.Apostrophe.png) is 128x128px and probably scaled up to 256x256px. In the requirements for application icons either .svg or a .png with at least 256x256px is defined. The original icon of Apostrophe from the screenshot for example is provided as a .svg. Is flathub creating the png version used on the website and only generates 128x128px files?

[razzeee]

Yes that's here https://dl.flathub.org/media/org/gnome/gitlab.somas.Apostrophe/79e84cd62f433972088419e196bc13ff/icons/128x128@2/org.gnome.gitlab.somas.Apostrophe.png

But you can always zoom in deep enough, to make it blurry - not much we can do here.

[PhilippSua]

I'm not zooming to 200% with my browser. I have 200% scaling enabled in GNOME because I have a HiDPI screen. I'm not asking flathub to support an arbitary high resolution for icons here. But if you use 128x128 px icons on the website you should provide 256 x 256 px icons for HiDPI screens too. Otherwise Flathub looks blurry for everyone with a modern HiDPI screen like for example 2880x1800 14-inch laptops.

App icons appear blurry in GNOME Software too on HiDPI screens: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2559

[razzeee]

Blocked on #1453 then as this would bog down smaller screens / bad connections otherwise

[PhilippSua]

Blocked on #1453 then as this would bog down smaller screens / bad connections otherwise

I think a CDN as mentioned in #1453 might not be needed to accomplish using different PNGs at different integer scale levels. PNG are already available for 2x integer scale and most up to date browsers should support the scrset attribute (https://caniuse.com/srcset). I assume something like the following should work:

<img src="/images/mylogo-default.png"
  srcset="/images/mylogo-density1.png 1x, /images/mylogo-density2.png 2x">

img src defines the default png used when the browser doesn't support the srcset attribute.
srcset prpvides two variants for standard (1x) and double (2x) pixel density.

See: https://www.nginx.com/blog/responsive-images-without-headaches-nginx-plus/#element-attrdef-img-srcset

[PhilippSua]

I have tested my approach by manually editing the html of Flathub's website using the Firefox developer tools like this:

<img alt="Biblioteca Logo" aria-hidden="true" loading="lazy" width="128" height="128" decoding="async" data-nimg="1" style="color: transparent; max-width: 100%;" src="https://dl.flathub.org/media/app/drey/Biblioteca/0ddd95726933bb60f74ca1fd63c3de78/icons/128x128/app.drey.Biblioteca.png"
srcset="https://dl.flathub.org/media/app/drey/Biblioteca/0ddd95726933bb60f74ca1fd63c3de78/icons/128x128/app.drey.Biblioteca.png) 1x, https://dl.flathub.org/media/app/drey/Biblioteca/0ddd95726933bb60f74ca1fd63c3de78/icons/128x128@2/app.drey.Biblioteca.png 2x">

It works :)

[razzeee]

I've added the Icons array some time ago on this endpoint https://flathub.org/api/v2/appstream/app.drey.Biblioteca

You can use it to get the correct icon paths, but it might be empty

[PhilippSua]

You can use it to get the correct icon paths, but it might be empty

Why can they be empty? Are the icons and specifically 128x128@2 not automatically created by the Flathub CI?

[razzeee]

No, they are only generated if the app has a scalable svg (or maybe if they provide a big enough png) and if they have been rebuild since we switched to libappstream

[PhilippSua]

Is it possible to check the availability of the @2 icons somehow and fall back to the default icon if it's not available?

[PhilippSua]

There is https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2559 tracking the corresponding issue about blurry icons in GNOME Software.

[razzeee]

Is it possible to check the availability of the @2 icons somehow and fall back to the default icon if it's not available?

You can do that via the Icons array.

[razzeee]

Trying to use srcset via nextjs seems broken for our use case

vercel/next.js#27547