[AppStream] Rethink how we handle the icon cache in AppStream

[Corentin Noël]

The major problem I see right now (and other people at elementary) is 
that the 128px icon *is* a completely different icon from 64px at 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.
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…
Because re-downloading all the icons from the repository isn't a viable 
solution for the future.

Regards,
Corentin

Le jeu. 6 oct. 2016 à 22:44, Richard Hughes <hughsient at gmail.com> a 
écrit :
> On 6 October 2016 at 20:53, Matthias Klumpp <matthias at tenstral.net> 
> wrote:
>>  1) Graphics people told me that downscaling 64x64px icons to e.g.
>>  48x48px yields worse results than downscaling 128x128px to 64x64px -
> 
> Not unexpected, 64->48 is non power of two.
> 
>>  so, should we ship bigger icons by default and drop 64x64?
> 
> I think 64x64 would be sorely missed.
> 
>>  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?
> 
> 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.
> 
>>  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.
> 
> Also, there are quite a few files that render fine with inkscape but
> fail to render correctly with rsvg.
> 
>>  I would like to be convinced that SVGs are a good idea and render
>>  quickly enough before cosnidering to allow them.
> 
> And the memory footprint of doing so, especially for threaded apps
> like g-s that are doing lots of things all in parallel.
> 
>>  4) Issue https://github.com/ximion/appstream/issues/21 exists to
>>  properly provide different DPI for icons, instead of just declaring
>>  128x128px to be "HiDPI"
> 
> 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.
> 
>>  especially since there are only few apps shipping low-res icons
> 
> 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
> AppStream at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/appstream



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20161006/1a391fd7/attachment-0001.html>