Improving performance under breeze icons

[kainz.a]

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.
>
First I want to say that most 3rd party icon sets had the same issues,
cause they are available as svg files in same (not all) icon sizes.

I personaly prefere svg files cause that's the source and you can style them


>
> 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.
>

About icon sizes we don't offer all sizes. We ordinary offer the main size
e.g. application icons are available in 48px which was used for the dash

the action, mimetype and places icons are available in different sizes,
cause svg files have NO scaling problem but breeze has a scaling issue.
if you scall a 22px icon with 1px thin "lines" to 16px the line is blured.

there is only ONE dictionary where you can "merge" the icons
action/22 and action/24 are the same icons where 24 has a 1px bigger margin.
BUT 24 px icons are ONLY for GTK apps (Inkscape, Firefox, ...) That's also
the reason why not all 24px icons are needed in 22px, ...


>
> * 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.
>
> emblem icons were made ONLY for the default size as I don't found an issue
I don't see the need to have all in all sizes. Uri was really strict with
sizes
Icon's are only needed in an specific size if it was needed anywhere.


> * 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.
>

That's a bug, but yes we have issues with monochrome icons and colored ones
cause some icons are needed in small size as monochrome and in big size
colored
There the big issue is 32px icons in size cause I'm not sure if they should
be
monochrome or colored. In addition one icon in different colores is a
problem.
Should be solved in the codebase of the app.


> Do you think there's any possibility we could improve there?
>
> Thanks a lot!
> Aleix
>

As I wrote in my blog post I cleaned the svg files
e.g. the widget explorer icons are now really small and should be way
faster to render

As a app developer you work on cpp, h files
when you are finished you compile your stuff to fit your platforms and to
improve the speed

It's the same here, Icons were made (not only for breeze) with svg files,
I don't want to include png files (in all sizes) to the source, cause than
it is not possible to
style icons according the color scheme.

I thought it worked that way that you select an icon set and the system
generate png files
with the defined color scheme. If the user change the color scheme or the
icon set,
the temp png files were generated again. This icon were used from the
applications.

cheers
Andreas Kainz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160427/08f997a9/attachment-0001.html>