<br>The major problem I see right now (and other people at elementary) is that the 128px icon *is* a completely different icon from 64px@2 so we *can't* say that 128px icon is the @2 icon size for 64px. Right now it's just that two different sizes are provided. <div>Maybe it would be better to have all the icons on a server side and accessing it on-demand (and caching the icons, but it's something the software center can do if it makes sense), so this mean doing it the same way it is done for screenshots right now…</div><div>Because re-downloading all the icons from the repository isn't a viable solution for the future.</div><div><br></div><div>Regards,</div><div>Corentin<br><div><br></div><div>

Le jeu. 6 oct. 2016 à 22:44, Richard Hughes <hughsient@gmail.com> a écrit :<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">On 6 October 2016 at 20:53, Matthias Klumpp <<a href="mailto:matthias@tenstral.net">matthias@tenstral.net</a>> wrote:
<blockquote> 1) Graphics people told me that downscaling 64x64px icons to e.g.
 48x48px yields worse results than downscaling 128x128px to 64x64px -
</blockquote>
Not unexpected, 64->48 is non power of two.

<blockquote> so, should we ship bigger icons by default and drop 64x64?
</blockquote>
I think 64x64 would be sorely missed.

<blockquote> 2) Many software centers want huge icons (KDE Discover, Elementary
 AppCenter), and if only the 64x64px icons are available, the
 experience isn't great. Again, should we waste more bandwith and
 diskspace and ship bigger icons by default?
</blockquote>
How many upstream apps ship an icon larger than 64px -- same question
again for 256 and 512? I can't believe 48x48 is even legible on a
hidpi screen. It's not like every upstream app ships 512px versions of
it's icons.

<blockquote> 3) Many people want SVG icons in AppStream too, which would solve the
 file-size problem, but SVGs render very slowly (Richard says up to 50x
 slower than PNGs). We need to render possibly hundreds of icons in
 AppStream GUI frontends, so if it really is that slow we should not do
 it.
</blockquote>
Also, there are quite a few files that render fine with inkscape but
fail to render correctly with rsvg.

<blockquote> I would like to be convinced that SVGs are a good idea and render
 quickly enough before cosnidering to allow them.
</blockquote>
And the memory footprint of doing so, especially for threaded apps
like g-s that are doing lots of things all in parallel.

<blockquote> 4) Issue <a href="https://github.com/ximion/appstream/issues/21">https://github.com/ximion/appstream/issues/21</a> exists to
 properly provide different DPI for icons, instead of just declaring
 128x128px to be "HiDPI"
</blockquote>
Why not declare that 512x512 or 256x256 is the new HiDPI? Anything
powerful enough to have a HiDPI screen is going to be capable of
scaling an image to an integer division in super quick time. We just
then ship 64x64 always and then the biggest of the available 128, 256
or 512 icons.

<blockquote> especially since there are only few apps shipping low-res icons
</blockquote>
I think this is a good point; unless _everything_ ships HC icons it
looks basically awful. The same effect can be seen when you see a
toolbar with 90% symbolics and 10% full color icons; it just looks
really bad.

Richard.
_______________________________________________
AppStream mailing list
<a href="mailto:AppStream@lists.freedesktop.org">AppStream@lists.freedesktop.org</a>
<a href="https://lists.freedesktop.org/mailman/listinfo/appstream">https://lists.freedesktop.org/mailman/listinfo/appstream</a>
</div></blockquote><br><br>
</div></div>