Am 03.09.20 um 16:53 schrieb Miklos Vajna:
>* Design team discussed two-years plan in weekly meeting: a vision
> + Retire PNG variants of icons
>+ interested in replacing that with SVG
>+ what is the goal here? (Kendy)
> + problem on hi-res screens: PNG is blurry (Heiko)
> + rendering SVG is expensive (Kendy)
>+ if you want to have the same perf as PNG, you’ll need a cache
>+ you need to build that cache on first start
>+ could just generate that at build-time
>+ not exicted to generate them on the user’s machine
>+ Tomaz says: SVG icons already have a cache (Thorsten)
> + switching to SVG won’t buy us anything, it’ll be still blurry
>+ don’t like the slow cache building at start (Heiko)
> + just the messenger here…
>+ SVG has to be designed in a way that is cheap to render (Kendy)
> + done with care, in some optimized way
> + PNG is just an impl detail; design team does SVG, we use PNG at
> runtime (Thorsten)
>+ more a dev decision
>+ agreed (Kendy)
The primary bug is
https://bugs.documentfoundation.org/show_bug.cgi?id=115439
I brought this up, because it's a UI problem with many duplicates.
The used icons in the LO UI are always (scaled) PNGs of the original
icons, which can be PNG or SVG, in any non-100% / 96 DPI setting, cached
in the user profile.
The discussion was never about rendering runtime SVG icons. And all the
points mentioned in the notes about caching are already more-or-less
addressed and implemented since quite some time. But currently the user
has to manually select an SVG iconset. Per default the user gets scaled
PNG icons for HiDPI and indeed the result is blurry / blocky.
And - as I understood Tomaz - the complete iOS GUI is rendered via SVGs,
so generally our SVG renderer seems fast and correct enough for simple
stuff, but he also said there are workaround for bugs, if I understood
him correctly.
But coming back to the original bug / suggestion to retire the PNGs: the
quality of the SVG renderings of the icons at 100% isn't good. They look
"washed out" in comparison with the unscaled, alternative PNG icons. I
guess the current PNGs are generated by other renderers already from the
existing SVGs, but I don't know.
In the end people claim this is primary a problem of LO's SVG renderer.
So my suggestion was to create a tender to address the most prominent
SVG rendering problems in LO, so the PNG icons can be dropped in the
optimal case, or the SVG icons can at least become the default. The bug
just suggests to always use SVG versions of an iconset, if you must
scale the icons.
This probably / eventually needs some design people to identify the most
prominent problems they see when working on icons, which would need
fixing. At least it seemed like some actionable work, which could be
done by that team, and also would benefit LO in multiple ways.
Hope this makes my proposal a bit more understandable.
Jan-Marek
P.S. AFAIK the current implementation of the cache isn't aware of the
original icon, so it won't update icons on source changes. And FWIW the
internet has various blog posts about selecting an SVG iconset in LO,
but from my POV this shouldn't be a problem to begin with. Others also
suggested to internally replace SVM with SVG, which is out of scope of
my proposal, but better SVG support would help there too. And there is
even https://github.com/GarkGarcia/icon-pie/issues/14, which suggests to
use an external program to render the scaled SVG PNG icons, which is
just an other workaround.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
