Real data for a single Kexi start + opening a single document on Linux, SSD:
strace kexi 2>&1 | grep ^stat | wc -l
1. Traditional icon files: 78k calls
2. .rcc icon files: 11k calls, starts ~14% faster
And for #2 there are still a few thousands of lookups
(*/icons/hicolor/16x16/devices etc.) for icons probably at KF5 and KIO
level and alike - they can be reduced only if traditional icon files are
uninstalled or installed away from the default search path.
Each stat() on Windows would take more time.
On 7 March 2016 at 15:53, Jaroslaw Staniek <stan...@kde.org> wrote:
>
>
> On 7 March 2016 at 14:45, René J.V. <rjvber...@gmail.com> wrote:
>
>> On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote:
>> >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi.
>>
>> That sounds inherently wrong unless the application adds icons to
>> specific themes. Icons that are specific to an application are (almost) by
>> definition not part of a theme, so expecting QIcon::fromTheme() to return
>> them seems a bit of a misunderstanding.
>>
>
> I am using the icons theme infra for this. Alternative would be to
> duplicate the code to achieve exactly the same. QIcon(filename) does not
> even support multiple sizes; you need to code this. Note how a Kate plugin
> I mentioned above uses hardcoded
> ":/katesql/pics/16-actions-sql-field-pk.png" file.
> Please also note I am not mixing breeze theme and app's breeze icons. They
> are separated.
>
>
>> >Without that I'd have to duplicate logic of icon themes just to make
>> QIcon::fromTheme() work cross-platform.
>>
>> Why? Why not do as Kate and use QIcon(":/icon-from-rcc") instead of
>> QIcon::fromTheme() for app-specific icons that should be independent of the
>> user's icon theme choice, and ::fromTheme() for those icons that are
>> supposed to reflect his/her choice of theme?
>>
>
> Because I am not reflecting the choice in Kexi's icons. The only that are
> produced (takes weeks) and referenced in docs are the breeze ones. Anyone
> is free to start project aimed at supporting another theme. This is a
> switch in philosophy to boost the quality, and I accept you may disagree.
> But how icons are packaged distributed should reflect the development
> process and priorities of the app project.
>
>
>>
>> I don't think there's any need whatsoever to duplicate (reimplement) the
>> logic of icon themes. AFAIK, QIcon::fromTheme() will work anywhere once you
>> define an icon theme search path and the expected icon theme is installed
>> somewhere in that path.
>>
>> BTW, am I right that using a builtin binary rcc icon set could make you
>> lose in terms of memory (RAM) footprint overhead what you gain in terms of
>> disk space overhead?
>>
>
> With all due respect. Dunno. I am writing this email in a 2GiB large
> email client (GMail in Firefox).
> With thousands of cached icons and copies of jQuery. We're still super
> light.
>
> As David Faure said not once here, technically we just don't have KDE apps
> anymore. We have Qt apps. We can't assume themes are installed, properly
> installed, or caching is in place. Optimizations is the 1% remaining thing.
> I know no user who abandons software because of such things. Mac had
> universal binaries for years, with interesting growth in size. FatELF,
> application containers, all these are approaches that spend a few bytes in
> exchange for convenience, security, etc.
>
> My kexi_breeze.rcc is 184
> k an full (unoptimized) breeze.rcc is 14M compressed 35MiB fully
> uncompressed, while my wallpapers on just 2 screens are 18M compressed,
> ~120MiB in graphics RAM. And many of the icon file take >=4096 bytes
> despite being 2048 bytes large.
> I guess you also know that random-accessed files are mmapped and read on
> demand. Though I bet a 14M file will be read-ahead on any todays system.
>
> 2016 calling :) The resource files are easily handled in my years-old
> smartphone, so...
>
> There's nearly zero stat() calls for icons discovery instead of thousands
> per (even tiny) app.
> And packagers can easily package breeze.rcc (I'd recommend this in a
> README.PACKAGERS file).
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
