Add support for 48px icons

[danirabbit]

appstream-generator/src/asgen/handlers/iconhandler.d

Line 55 in 91c04ab

public immutable wantedIconSizes = [ImageSize (64), ImageSize (128), ImageSize (64, 64, 2), ImageSize (128, 128, 2)];

AppCenter uses 48px icons in list views. Since this is a standard Gtk.IconSize it would be great to have it supported :)

[ximion]

The specification explicitly forbids icons smaller than 64x64px, and I really do not want to add yet another icon tarball that people need to download. Just scale down the 64x64px icons.
The generator will ignore any application that has only icons smaller than 64x64 anyway.

Cc: @hughsie

[hughsie]

48px is tiiiiiiiiiiiny on HiDPI screens.

[ximion]

It's also even more data to download on every apt update call and breaks with the AppStream spec (which mandates a minimal icon size of 64x64 and guarantees that to be available).
Which problem would having 48x48px icons solve?

[danirabbit]

Hey Matthias, it’s a very common misconception that you can “just scale down” a large image and it will be fine, but that’s how you end up with a blurry, sloppy looking interface.

Richard, the way Adwaita treats HiDPI is wrong. That’s why we’ve been pushing for @2 assets. Icons are not like pictures, they are more like fonts. They need to remain legible at each display size and this often requires some kind of “hinting”. On a HiDPI display you would have an icon that was designed to be displayed at 48 logical pixels (or points or dots or whatever you want to call this unit), but the image would be 96px (48@2). This does not imply that a 96px image is interchangeable with a 48px image.

I have a blog post about this if it’s still unclear: http://blog.elementary.io/post/124193007916/whats-up-with-hidpi-icons

[hughsie]

I understand the difference between 64@2 and 128px icons. The issue here is one of standardization -- if KDE wants to use 96px icons, GNOME 128px and Elementary 48px icons we end up shipping a huge number of pixmaps. If we also support 96@2, 128@2 and 48@2 we've just doubled the storage and download space yet again. The pragmatic decision is to ship one size of icons with a single HiDPI variant. Perhaps Elementary could just use 64px icons rather than 48px icons? Or downscale /2 and use 32px.

[danirabbit]

Hey Richard, as I said before simply stretching the icon to a smaller size looks bad and we have people complaining about how unprofessional it looks. Using 64px icons in a list view is a little excessive.

I understand it’s more data to download, but that’s up to the distro to make sure they have a configuration that only downloads the sizes they need. This is kind of a moot problem though anyways since downloading all of the app metadata is already an unscalabe practice.

If your primary concern is storage space, one thing to consider is not rendering SVG icons into scaled pixmaps. If GNOME apps are happy to just downscale large images then I don’t see how this would effect you at all. I’m happy to pay the hosting costs on our servers to have correctly rendered icons.

[snwh]

Any icon size less than 64x64 needs to be drawn out specifically, just scaling is just sloppy and looks unprofessional/unpolished. Applications have dedicated icons for 48, 32, 24 (sometimes 22) and 16 versions, precisely because there is a limit to how far you can downscale a the high resolution of the icon without losing clarity and detail, for example the Polari icon I drew:

So it'd be great to have at least one of these smaller icon sizes available for use in user interface elements where 64x64 is too large, especially in a list view as @danrabbit said.

[hughsie]

You can lobby as much as you like for 48px, but it's really not going to happen. You can replace the same arguments for 48px as 96px and then before you know it you're shipping hundreds of megabytes of icons.

[danirabbit]

If that is how you view other people than GNOME consuming this utility then it sounds like our long term goal should be to move away from using asgen.

[sramkrishna]

@hughsie so let me summarize this discussion. You're saying that this is a general scaling issue that we can't just pick every random icon size and accept them because the size of the distribution is exponential and that free desktop designers need select 3 2 standard icons sizes. Is that your position?

[ximion]

@.all Calm down ;-)
@danrabbit Richard isn't using asgen much, and we actually do want to help you here, but I also want to save the AppStream spec from an explosion of different icon combinations, especially because with the way this system works users will download them. It also will not help you much if I merge a patch for this for you in asgen, because the AppStream spec makes different claims on icon availability and changing that will be a breaking change for users of AppStream. Additionally, Richard would need to implement the changes in his library as well, making this even more complicated.

@sramkrishna That summary is accurate. Choosing 64x64px as default icon size was a compromise we made in 2011 (!) because it is likely that applications have icons of that size or bigger icons that we can scale down, and because it's a balance between space requirements and the "we want to ship the biggest icon" mentality.

I would really like to reduce the amount of icon sizes generated to an absolute minimum. On Debian we now ship 64x64px and 128x128px icons, both at scaling x1 and x2, amounting to about 44MB already (gzip compressed, unstable suite). We only fetch these files if a software center is installed, but installing AppCenter would make users download all of these files every single time they run apt update. (with installing gnome-software, you fetch only the 64x64px icons, with KDE Discover the 64x64px and 128x128px icons, both don't use scaled icons by default yet). We could maybe make some binary-diff delta download thing in the future, but even in that case these files will take up space on the users' systems.

So, if we ever add another icon size, an existing one would need to be dropped first (and doing that is hard, as it breaks expectations guaranteed by the spec).

[danirabbit]

I don't think that file size is a great argument here since it's already totally unscalable to download all of these assets when performing apt update. This is already a broken model that doesn't work with repositories that might contain hundreds of thousands of apps. I agree that we need some kind of solution for this in the future whether that's delta updates or fetching metadata on demand, but I think that's an entirely separate issue.

Currently in AppCenter we use three icon sizes: 48px, 64px, and 128px and we do need to support HiDPI and LoDPI. Not having any of these 6 sizes is not really acceptable for us. From my perspective, I would like to be able to configure asgen on our servers to supply whatever icon sizes that we use in AppCenter. I don't see how that has any bearing on what sizes that Debian or Fedora should supply. This is configuration that is specfic to our distribution.

[sramkrishna]

OK, let me ask this - is moving from 48x48 -> 64x64 an easier direction? I see that downscaling leads to loss of resolution. But what about the other direction? Can we revisit the defaults? In 2011, the number of designers in the free software world was probably quite small. We have a lot more now in a lot more desktops.

What is driving 48x48 ? I realize that is a standard 48x48 Gtk.icon size but what else is part of the calculation? Less data to download for icons? Render speed? Trying to understand how we can all get what we want while adhering to the spec, or maybe even change the spec?

[danirabbit]

@sramkrishna both upscaling and downscaling are not acceptable solutions. They both result in a loss of quality that our users have noticed and complained about.

64px icons are great on discovery views such as the homepage where we display a large carousel, but they are comically large in views like the updates view or when we want to show a list of extensions on an app's info page. We need to have a smaller icon size available for these kinds of views in addition to the large sizes that we use elsewhere

[hughsie]

I'm not commenting on this issue anymore due to
https://plus.google.com/+DanielForé/posts/gCQZFtTqt6h

@ximion it's up to you as the appstream maintainer but you know my position already.

[danirabbit]

I think maybe what would make everyone happy is if this could be configurable on the server rather than hardcoded. Then Debian and Fedora and the like can stick with the default sizes (or fewer if they so desire) and we can have more sizes on our server. I'll readily admit that this problem is specific to our client/implementation and if other distros/clients don't experience it then I agree they shouldn't be punished in order to try to fix it.

[cassidyjames]

@allanday's latest designs for GNOME Software also use 48px icons, so this is likely to be an issue GNOME hits as well. If the technical constraints aren't acceptable for GNOME or other downstreams, how would we go about revising the spec and technical implementation to better accommodate the projects using AppStream?

[allanday]

@allanday's latest designs for GNOME Software also use 48px icons, so this is likely to be an issue GNOME hits as well. If the technical constraints aren't acceptable for GNOME or other downstreams, how would we go about revising the spec and technical implementation to better accommodate the projects using AppStream?

I might be splitting hairs here, but this implies that the current situation isn't acceptable to the GNOME project. That's a bit of an overstatement as far as I'm concerned. I would be interested in having a conversation about how we might use more icon sizes though. :)

[Conan-Kudo]

I really shouldn't be wading into this mess, but as I am actively working on AppStream stuff in Mageia, and we actually implement AppStream repodata (as opposed to appstream-data packages like Fedora does).

Because of how we provide our AppStream metadata, we're very sensitive to the data sizes of the tarballs. Today, the Mageia 6 core release repository metadata is approximately 45MB compressed (it's about ~3x-5x that decompressed). This includes both AppStream and regular metadata. The more icons that are stuffed into the generated metadata, the bigger this chunk of data gets.

While I enjoy high-bandwidth Internet access and have lots of disk space, many of our users do not. Heck, many of our developers and packagers don't either! It does no one any favors to unnecessarily expand the amount of metadata downloaded and decompressed on disk.

When it comes specifically to icons, it's my view that we don't need a large number of sizes. The reason being is that these icons are not displayed by anything that uses many of the smaller sizes. Really, the icon is used in software center search (which uses the large 64x64 icon) and in the detail view of the application in the software center (which also uses the 64x64 icon). The remaining icons only make sense for normal usage of the app, which is not what AppStream serves.

[ximion]

@danrabbit First, I am not only a GNOME developer (but also KDE and Freedesktop stuff). Second, you can generally talk to people and reach some sort of agreement that works for many parties with some patience. One way to ensure that never happens though is to burn bridges by publicly complaining about "them" or even worse an individual developer.
People who know me know that I try to make things work for all desktops and applications, regardless which toolkit they use. But I will not make a project loose its focus or make it harder to maintain, that has an even higher priority (I did learn from past mistakes here).

That being said: Allowing people to configure appstream-generator to throw out more icon tarballs is something I could live with, as long as 64x64px icons are always present and their availability continues to be enforced by the generator.

@allanday Hey :-) I would actually like to have that discussion. KDE is pushing hard to allow SVG icons, which I did say no to because rendering a lot of them is really slow according to @hughsie (I haven't yet benchmarked this, especially because the definition of "a lot" varies - maybe QtSVG is also much faster than rsvg).
I also actually did wonder whether we should have 48x48px and 128x128px as the default icon sizes. In any case, I do want the specification to have one size as "this is the one you at least have to ship" for application authors, as well as one size that software center developers can expect to be present at all time.

For some software centers at some point, downloading additional icons on demand may also be an option (using the "remote" icon type) - this will not work for projects like Endless or for distributions that are very worried about privacy.

[danirabbit]

@ximion I have absolutely never had any problems discussing anything with you at any point in the past or in this discussion. You've been extremely accommodating and we've made a lot of progress by having a positive relationship with you. I apologize if you feel like I've ever harbored any animosity towards you.

My complaints are entirely directed at Richard who has made it clear that he does not wish to participate in any sort of discussion and consequently the politics that have ensued. I did delete my (admittedly very frustrated) post elsewhere after a couple of private conversations with other GNOME community members to make sure that I didn't implicate anyone besides the person who is causing the problem. I'm here to write code and I would like to have a technical discussion where we can reach a conclusion that fits the needs of the various freedesktop projects in a way that makes everyone happy. What I'm not happy with is Richard attempting to dictate what is and isn't up for discussion, especially when you and I have had such a productive and positive relationship so far. I don't think that refusing to discuss the problem represents the kind of attitude we should take towards each other when the goal here is for everyone to collaborate.

I would be super happy with continuing to enforce the existing sizes, while adding the ability to configure the server to provide other sizes. I'm interested in providing more sizes, not changing the required sizes :). I would also be really interested in using SVG icons instead of providing @2 tarballs if that's something on the table as far as file size reduction.

[hughsie]

Bringing up a contentious topic yet again... What about a compromise of shipping an optional 96px icon in addition to the other sizes? That gives us hidpi for "free" and can be downsampled 1/4 to 48x48 at lightning speed whilst looking sharp. We also then have the potential of having 192x192 or 96@2 icons in the future.

[danirabbit]

@hughsie That unfortunately doesn't work for elementary. We're designing icons at scale, so a 96px icon is not the same as 48px@2

[ximion]

@hughsie I fear we will add more and more icons until we basically cover the whole range of the icon theme spec - there are many software centers, and each one has new icon requirements for their UI. As soon as AppStream supports a lot more icon sizes, people will expect them to be there, and we'll need to download bitmaps for all icons - I already have bug reports from people finding the data downloaded for AppStream to be way too high right now and that is just with two icon sizes plus optional HiDPI icons.
The beauty of the original spec was that we didn't need to ship a massive amount of icons rendered to different sizes, and I don't really want to get to that point.

Therefore, I am considering to add scalable SVG and SVGZ icons to the allowed set of icons. The appstream-generator would run them trough a filter to filter out unwanted SVG features like scripts and animations. I was playing with the idea of writing a new shared library for that, adopting features of svgo (which is NodeJS based and something I don't want to depend on), but maybe running the SVG icons through scour could already be sufficient (we could also use Inkscape from the command line to optimize the graphics further).
This will give us smaller and (slightly) faster to render vector graphics which adapt perfectly to any size and screen resolution that software centers might come up with in future. Vector graphics unfortunately take much longer to render compared to bitmaps, and unlike a desktop icon theme, we can't really cache them properly. But I think that issue can be ignored, because any software center will not display more than 50 icons on the same page (massively less, I guess) and icons can be rendered on-demand. Also, computing power is high enough that rendering is reasonably fast (new Android versions also render vector graphics).
There is a drawback to vector graphics, but the benefits in this scenario start to outweigh the costs for me (and the reason we didn't support them in the first place).

[peteruithoven]

But that wouldn't solve the pixel fitting challenge? See: https://dcurt.is/pixel-fitting

Would you solution allow responsive svg's? Responsive svg's adapt their content to the size their are shown in using media queries in css. I don't know how well this is supported by non web svg rendering libraries. More info on responsive svg's
Examples:

• http://responsiveicons.co.uk/
• http://vagari.github.io/svg_queries/

[Conan-Kudo]

My understanding is that responsive SVG requires script execution to properly be rendered. I'm not sure how well that is handled by most non-browser SVG renderers...

[ximion]

@Conan-Kudo The icon-theme spec allows separate SVG icons for HiDPI purposes (scalable icons can have a min-size, max-size and a scaling factor assigned). For the scaling factor, AppStream could have scalable icons and scalable@2 icons, I guess (that way we don't need to support the script stuff).
If SVG is supported, I would really like to limit what people can do with it (most of the limits are already set by the capabilities of librsvg and QtSVG though).

[danirabbit]

Allowing SVG icons would solve HiDPI scaling with half as many assets, but it still wouldn't give us the icon sizes we need since icons are designed at size. In this context, scalable means scaling across DPI, not stretching or shrinking.

I don't think the spec should require any new icons sizes, but in order to support the various package manager apps, asgen should support distros optionally supplying them imo

[tintou]

I think that the best way would be to use DEP-11 for the 64px@1 only, and provide "remote" icons for the rest of the icons, so that Application Centres can use the 64px@1 while the other are downloaded.

[Conan-Kudo]

What I don't get is why you're using 48px in AppCenter, given that you already knew that 64px was the minimum for AppStream application iconography...

[tintou]

@Conan-Kudo What's the point in limiting the icon sizes, again the solution is to get images on-demand here, and in SVG format…

We are using different icon sizes because there are different contexts:

• 48px when they are in lists
• 64px when they are in button
• 128px when they are in plain view

The fact that the AppStream cache has limitations shouldn't be a reason to have bad application design. It just means that the tool is now showing its limits.

[kalev]

With my gnome-software developer hat on, I'd also love to have 48px icons available in addition to 64px, so that we could use them in different contexts. Would also be good to have matching @2 icons so that things would look right on hidpi.

[ximion]

We (kalev, hughsie, me) had some discussion on IRC a couple of days ago about this (in #PackageKIt, Freenode), and came up with the following:

AppStream itself

• AppStream will definitely keep the 64x64px requirement for apps - so, software centers can rely on that size always being present.
• I will allow 48x48px in the spec in theory, so the icon sizes that may be available are 48x48, 64x64* and 128x128px, with at least 64x64px being always present for each app, and other sizes might be unavailable.
• At this point, we won't rush to add SVG icons into the mix. I would like to have them at some point, but Richard and me would also really like to filter them a bit and limit what crazy things people can do with them. So, adding SVG icons likely depends on having a proper filter for them first.

appstream-generator

• I will add a bunch more configuration options to asgen to select which icon sizes should land in the output, and whether they should be remote or cached icons. 64x64px will always be there, and likely always be cached, but for the other two sizes options will be available.
• 48x48px icons will only be made available if they exist. Appstream-generator will not downscale anything for the client, they can downscale from the 64x64px icon in that case.
• On the other hand, there are a lot of apps that only ship 48x48px icons, and I have been asked multiple times to include those - so, when I touch this code already, I can just as well implement support for upscaling 48x48px icons. In that case though, asgen will throw a warning at the respective package, and that feature can be disabled.

Debian (and Ubuntu?)

On Debian, I am playing with the idea of making all 128x128px icons remote-only and have them delivered by our CDN, so we don't host a tarball for them anymore and ship that to the users.
I will likely though have the 48x48px icons downloaded by default, if 64x64px icons are downloaded. That should be a nice compromise between "downloading too much" and having many icon sizes available.
HiDPI icons, as always, will be downloaded on-demand if the right APT config snippet is there. I do plan to make the process of configuring that easier though.
I will also experiment with maybe having an optional 128x128px tarball for download, in case people want it (so, allow remote and cached icons). Let's see what works best in that case, and for what I get bug reports ;-)

Would that be okay for everyone? I don't know how quickly I can start working on these tasks though, since I am a bit tied up in Purism work at the moment.

[Conan-Kudo]

@hughsie What are your plans w.r.t. asbuilder? Both Mageia and openSUSE use asbuilder to make AppStream metadata that is appended to our rpm-md repodata, so I'm wondering how you intend to go about this?

[kalev]

Sounds like a good plan to me! Thanks ximion!

[hughsie]

@Conan-Kudo I wanted to discuss it a bit with @kalev on IRC next week. It's the gnome release on Monday so that's going to be busy for us. I don't know how much work it would be, I've not looked at the (quite scary due to the compatibility and legacy stuff) icon loader code in a long time.