Improving performance under breeze icons

[kainz.a]

HI

2016-04-27 2:26 GMT+02:00 Aleix Pol <aleixpol at kde.org>:

> Hi,
> As assessed lately, one penalty we have when starting an application
> is the icons look-up. It's not really Breeze's fault, the intersection
> of the standard we're using and how we're using it makes the situation
> slightly complex, hence simplifying it would improve the situation
> already.
>
I want to also say that most 3rd party icon set's have the same issue cause

>
> To get some context, the problem is that whenever we request an icon,
> what we do is go through all the provided directories hoping we'll
> find it.
>
> Now I'm mentioning breeze because on one hand, it's really awesome how
> we're using scalable icons directly but on the other hand we could
> look into leveraging it better. Here's some ideas, I'd especially like
> the icon designers' opinions so we can find the best situation.
>
> * There's some sizes that we can probably trim right away. Are icons
> in the 12 and 16 directory substantially different? Or 22 and 24? I've
> checked and pruning these would get us about 5% of failed accesses
> back.
>
> * Furthermore, I see there's some icons that aren't on every size (for
> example, vcs-added is only in 16 but not in 8 or 22). All in all,
> feels like it could be specifying broader categories, especially
> considering the scalable nature, such as emblems/small, emblems/big.
>
> * Last, slightly unrelated, there's a risk when the icon differs
> greatly (e.g. system-help) from a size to another we'll end up with
> unpredictable UI's, maybe it would be possible to rename them to
> reflect this.
>
> Do you think there's any possibility we could improve there?
>
> Thanks a lot!
> Aleix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160427/e1dc4c97/attachment-0001.html>