Improving performance under breeze icons

[Volker Krause]

Thanks for looking into this Aleix!

On Wednesday 27 April 2016 02:26:06 Aleix Pol wrote:
> 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.
> 
> 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.

Yep, Olivier Goffart and I were looking into this during the last Randa 
meeting, as icon lookup actually had become the single biggest cost in KMail 
startup.

There are two parts to this, lookup and SVG rendering.

File system lookup was already happening by purely creating a QIcon, no matter 
if the application ever rendered it or not. And it multiplies by the amount of 
sizes and search directories you have. Olivier fixed that in Qt, by using the 
GTK icon cache, a simple binary "database" per icon theme folder that allows 
very fast lookup without hundreds of stat calls per icon. This should be 
available in Qt with 5.6 or newer.

The second part is SVG rendering, which is a problem we didn't see with 
Oxygen. KIconTheme has a persistent pixmap cache to cover that.

Both of those combined would fix the problem I think. However, it might not 
yet be possible to get both at the same time. The GTK icon cache lookup path 
was only hit without our Qt platform plugin (ie. when not using KIconTheme), 
which obviously also means no persistent pixmap cache. This should be fixable 
by making sure KIconTheme uses the same lookup mechanics as Qt does nowadays 
(whatever that means practically, didn't check the code), giving us the best 
of both worlds.

In any case, when doing profiling in this area, measure with Qt 5.6+ and 
compare numbers with and without the platform theme plugin. And of course make 
sure you actually have the GTK icon cache files (ie. have gtk-update-icon-
cache found by ECM, the distros we checked back then seemed to already handle 
this correctly for their icon packages).

> 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
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160427/8e11d10f/attachment-0001.sig>