Hi, what about loading icons in PNG instead SVG? I think it speedup launch.
Am 02.09.2018 um 22:17 schrieb Jabier Arraiza:
Hi, what about loading icons in PNG instead SVG? I think it speedup launch.
Could you clarify what you mean by "loading icons in PNG"? a) Do you want to ship pre-rendered versions of the SVG icons? Or b) Do you want to pre-render PNGs from the shipped SVGs as part of the installation process / first launch sequence? c) Do you simply want to cache the rendering at runtime?
If a)/b) I feel like the slight increase in startup time might not worth the duplication of the content and complexity and maintenance effort (especially as we'd need multiple resolutions to account for all possible user-settable icon sizes and scaling factors on high DPI displays and it might be easy to still miss some in the end).
If c) we actually had some code for pre-rendering/caching icons previously (see the preference "Pre-render named icons", i.e. "/options/iconrender/named_nodelay") which is dead/unused now. If it helps performance it might be worth investigating to revive it. Otherwise it should probably be removed at some point.
Best Regards, Patrick
It's worth measuring the time delay between loading svgs vs. loading pngs.
I can see for example us making sure Windows and Mac builds ship with PNG files. But only if the time difference is more than 2x (And I think it might be tbh, the delay in caching icons has been a problem for a while)
On linux systems it's often possible to let the user know that something is happening.
Best Regards, Martin OWens
On Sun, 2018-09-02 at 23:13 +0200, Patrick Storz wrote:
Am 02.09.2018 um 22:17 schrieb Jabier Arraiza:
Hi, what about loading icons in PNG instead SVG? I think it speedup launch.
Could you clarify what you mean by "loading icons in PNG"? a) Do you want to ship pre-rendered versions of the SVG icons? Or b) Do you want to pre-render PNGs from the shipped SVGs as part of the installation process / first launch sequence? c) Do you simply want to cache the rendering at runtime?
If a)/b) I feel like the slight increase in startup time might not worth the duplication of the content and complexity and maintenance effort (especially as we'd need multiple resolutions to account for all possible user-settable icon sizes and scaling factors on high DPI displays and it might be easy to still miss some in the end).
If c) we actually had some code for pre-rendering/caching icons previously (see the preference "Pre-render named icons", i.e. "/options/iconrender/named_nodelay") which is dead/unused now. If it helps performance it might be worth investigating to revive it. Otherwise it should probably be removed at some point.
Best Regards, Patrick
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 03.09.2018 um 01:52 schrieb doctormo@...400...:
It's worth measuring the time delay between loading svgs vs. loading pngs.
Having some quantitative data will certainly make it easier to make an informed choice and decide how to proceed.
I can see for example us making sure Windows and Mac builds ship with PNG files.
How is Linux different from everything else? Or did you mean it's easier to implement a post-install hook on Linux? Still I'm afraid it might make packaging on any OS more fragile / complicated.
But only if the time difference is more than 2x
I'd even go as far as to say if the difference in startup times differs by more than a factor of 2. First of all we need to know how much of the overall startup time is actually caused by rendering SVG icons. If we'd speed up loading of icons significantly, but loading of icons was only a fraction of the overall startup time, the gain would still be negligible.
(And I think it might be tbh, the delay in caching icons has been a problem for a while)
Are you sure you're not confusing this with the delay of crating the font cache? That's the only notable delay I'm aware of on Windows, and it has been addressed in fontconfig recently.
Regards, Patrick
On Sun, 2018-09-02 at 23:13 +0200, Patrick Storz wrote:
Am 02.09.2018 um 22:17 schrieb Jabier Arraiza:
Hi, what about loading icons in PNG instead SVG? I think it speedup launch.
Could you clarify what you mean by "loading icons in PNG"? a) Do you want to ship pre-rendered versions of the SVG icons? Or b) Do you want to pre-render PNGs from the shipped SVGs as part of the installation process / first launch sequence? c) Do you simply want to cache the rendering at runtime?
If a)/b) I feel like the slight increase in startup time might not worth the duplication of the content and complexity and maintenance effort (especially as we'd need multiple resolutions to account for all possible user-settable icon sizes and scaling factors on high DPI displays and it might be easy to still miss some in the end).
If c) we actually had some code for pre-rendering/caching icons previously (see the preference "Pre-render named icons", i.e. "/options/iconrender/named_nodelay") which is dead/unused now. If it helps performance it might be worth investigating to revive it. Otherwise it should probably be removed at some point.
Best Regards, Patrick
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
unknown＠example.com -
Jabier Arraiza -
Patrick Storz