[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: RCC for icons - update: Re: Icons installed by apps
From: Jaroslaw Staniek <staniek () kde ! org>
Date: 2016-03-07 15:21:44
Message-ID: CAOj7QQ2D8B1ijmHsQoL=yOivENgPsELAazdks0YEM6WbOLceyQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <staniek@kde.org> wrote:
>
>
> On 7 March 2016 at 14:45, René J.V. <rjvbertin@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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br>Real data for a single \
Kexi start + opening a single document on Linux, SSD:<br><br>strace kexi 2>&1 \
| grep ^stat | wc -l<br><br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">1. Traditional icon files: \
78k calls<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">2. .rcc icon files: 11k \
calls, starts ~14% faster<br><br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">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.<br></div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">Each \
stat() on Windows would take more time.<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 7 March 2016 at 15:53, Jaroslaw \
Staniek <span dir="ltr"><<a href="mailto:staniek@kde.org" \
target="_blank">staniek@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_extra"><br><div class="gmail_quote"><span class="">On 7 March 2016 at \
14:45, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" \
target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span>On Monday March 07 2016 12:41:52 Jaroslaw \
Staniek wrote:<br> >I am trying to use app-defined icons through \
QIcon::fromTheme() in Kexi.<br> <br>
</span>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.<br></blockquote></span><div><br><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">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.<br>Please also note I am \
not mixing breeze theme and app's breeze icons. They are separated. \
<br><br></div></div><span class=""><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span><br>
>Without that I'd have to duplicate logic of icon themes just to make \
QIcon::fromTheme() work cross-platform.<br> <br>
</span>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?<br></blockquote></span><div><br><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></div> \
</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
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.<br> <br>
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?<br></blockquote></span><div><br><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">With all due respect. \
Dunno. I am writing this email in a 2GiB large email client (GMail in \
Firefox).<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">With thousands of cached \
icons and copies of jQuery. We're still super light.<br></div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">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. \
<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"></div><span><br><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">My \
kexi_breeze.rcc is 184</div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">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.<br></div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">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.<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline"><br><span>2016 \
calling :) The resource files are easily handled in my years-old smartphone, \
so...<br></span><br><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline"><span>There's \
nearly zero stat() calls for icons discovery instead of thousands per (even tiny) \
app.</span></div></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline">And packagers \
can easily package breeze.rcc (I'd recommend this in a README.PACKAGERS \
file).<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></span></div></div><span \
class="">-- <br><div>regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network \
of software engineers, artists, writers, translators<br>: and facilitators committed \
to Free Software development - <a href="http://kde.org" \
target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office \
suite - <a href="http://calligra.org" \
target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder \
- <a href="http://calligra.org/kexi" \
target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a \
href="http://www.linkedin.com/in/jstaniek" \
target="_blank">http://www.linkedin.com/in/jstaniek</a></div> </span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div \
class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide \
network of software engineers, artists, writers, translators<br>: and facilitators \
committed to Free Software development - <a href="http://kde.org" \
target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office \
suite - <a href="http://calligra.org" \
target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder \
- <a href="http://calligra.org/kexi" \
target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a \
href="http://www.linkedin.com/in/jstaniek" \
target="_blank">http://www.linkedin.com/in/jstaniek</a></div> </div>
[Attachment #6 (text/plain)]
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic