appstream

appstream copied to clipboard

As it is the case with icons, we should take care of @2 screenshots in order to get better looking descriptions

Just take a bigger screenshot size or scale up a smaller one?

The problem is that the screenshot is taken in the DPI of the client, here is an example:

If you're on an HiDPI device, you'll see that the first screenshot is blurry when the second one is perfect

@hughsie What do you think in terms of bloat vs. usefulness? Adding scaling will - if we do it in a compatible way which we obviously should - mess up any SC that encounters it and doesn't use a recent enough version of AppStream that supports this feature (we did this in the past though).

In terms of space, the screenshots will consume a bit more on AppStream data servers, which shouldn't be an issue. All in all, I don't see that many drawbacks to this, except that the number of projects that will supply scaled screenshots is likely really small (but that's okay, as long as Elementary uses this ^^).

A simple scale property like we do with icons would suffice here, likely, or maybe we should directly add a dpi property to the <image/> tag, so the SC can fetch the screenshot matching closest to the dpi of the screen...

Another thing wonder about is whether we should go all the way and also think about a formfactor property for screenshot images, which could be tablet, phone, screen, hi-dpi-screen etc, for apps that display differently depending on the screen resolution... (Long-term plan ^^)

I think @2 makes sense, as does scale=2 but I'm vetoing dpi as it's almost impossible to get the actual DPI of a screen.

That would be great to have, especially as high DPI screens are less and less rare, and even more since we have appstream-powered phones which all use scale 2.

Having an integer scale="2" property for images on screenshot elements makes a lot of sense to me... Is fractional scaling a thing to be concerned about here, so would we ever have scale="1.83254"? Because I think that would be a nightmare to support properly. If the same scaling support that we already have for icons is good enough for screenshots, then I'm happy with adding it. Then we would only need to hope that upstream projects actually add the right metadata ;-)

@ximion generally the way that works on the web (and possibly even in GTK?) is that the next-highest integer image would be loaded and then scaled by the toolkit/browser/etc. So as long as you support integers in the spec, clients should be able to do what they need with non-integers.

(Since partial pixels don't exist, I don't think it's reasonable to try and support non-integer images anyway; it would generally look the same as the 2× image scaled down to 1.83254× :wink:)