Pixeled icons with LibreOffice 5.1.6.2 on HiDPI/4K display

Description:
In the current Icon-Sets there are already some Icons that exist in png AND svg versions. During my research for Bug 114699 I noticed, that the png versions can be deleted and LibO then uses the svg-versions of those Icons. Result is, that those Icons looks WAY better (perfectly sharp, no alias) then the upscaled png-versions.

So the question is, why does LibO still prefer the png-versions over the svg-ones?

Steps to Reproduce:
Open Writer (for example) and look at the icons.

Actual Results:
They look badly (at least on HiDPI Screns).

Expected Results:
The svg-icons should be used instead which look way better.

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.121 Safari/537.36 Vivaldi/1.95.1077.41

Hi

I know that libreoffice can use svg icons but the rendering is bad. So if you tell me that the svg rendering work well this is awesome. I will test it.

In the past only the breeze icon theme was available in svg so it wasn't to important to force the svg bug for me.

For 6.0 I update the elementary icon theme and with 6.1 an additional icon theme will be ready and available in svg.

Thanks for the feedback and please test as much as possible.

It would be really awesome if the svg support would work perfect but we are not there. As long as the png files look better they have to be generated.

In windows the svg support is better than on linux fyi, but also not perfect.

If needed I can upload the breeze_svg and elementary_svg icon theme to the extension webpage.

There are still a few issues but there is light at the end of the tunnel http://nabble.documentfoundation.org/Re-minutes-of-ESC-call-tt4229391.html#a4229645

Well, for me (on Windows) the SVG Rendering was perfect, but I tested only a few Icons that were available in the Tango-Set (I only deleted the PNGs where SVG where present). So, absolutely possible, that some icons don't render right, when there are attributes missing in the SVG.

But if a patch already exists, and only needs testing, Icon Sets could soon be delivered in SVG at least on Windows :)

PS: Does anybody have a link to Tango Icon Set in SVG? Would be interesting to see how many icons really are broken...

Tested the svg icon theme on linux work really good for me. In Virtualbox I had problem on a linux guest system. don't know why.

When I have time I'll upload the svg icon themes to the extension webpage.

(In reply to andreas_k from comment #5)

wrong icon theme the rendering on linux is way not perfect.

Yes, gtk3 backend has issues (because we use his way of doing HiDPI), which I know how to resolve (already did a proof-of-concept) but I need some spare time to implement it properly. The issue is described in ESC minutes...

*** Bug 115912 has been marked as a duplicate of this bug. ***

*** Bug 105489 has been marked as a duplicate of this bug. ***

*** Bug 105778 has been marked as a duplicate of this bug. ***

*** Bug 105950 has been marked as a duplicate of this bug. ***

*** Bug 106191 has been marked as a duplicate of this bug. ***

*** Bug 106682 has been marked as a duplicate of this bug. ***

*** Bug 110356 has been marked as a duplicate of this bug. ***

*** Bug 110457 has been marked as a duplicate of this bug. ***

*** Bug 114444 has been marked as a duplicate of this bug. ***

Dear Tomaz Vajngerl,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.

*** Bug 117158 has been marked as a duplicate of this bug. ***

*** Bug 117846 has been marked as a duplicate of this bug. ***

Wasn't work just done to introduce new icons in 6.1? Would it have made sense to work this as part of that?

Is calling this an enhancement accurate? It's a bug for hi dpi screens, which are really common nowadays. I would think when the interface breaks even if not functionally broken that it's an issue from a usability perspective. I love LibreOffice, but I keep reverting back to 5.2 so that the UI isn't broken.

*** Bug 120851 has been marked as a duplicate of this bug. ***

*** Bug 105489 has been marked as a duplicate of this bug. ***

Please notice bug 121130. [Nevertheless, I support to release the svg-themes as soon as possible.]

Definitly true but only when the renderer give us the same quality as the png one.

*** Bug 122536 has been marked as a duplicate of this bug. ***

*** Bug 123480 has been marked as a duplicate of this bug. ***

Changing priority to 'high' since the number of duplicates is 5 or higher

(In reply to andreas_k from comment #24)
> Definitly true but only when the renderer give us the same quality as the
> png one.

As long as the quality didn't work, I will block the patch.

Just updated to Version: 6.4.0.3 (x64)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8

First build since tracking the blurry/poorly rendered icons on high dpi screens that I've seen the issue fixed.

On a high dpi monitor (4k), seeing every SVG icon set render as expected, nice and crisp.

Not sure if my comment belongs here or a related issue. Just wanted to share.

(In reply to Matt from comment #29)
> Not sure if my comment belongs here or a related issue.

Thanks for the feedback. SVG is indeed the future, and once we have finished the testing phase we will switch completely.

SVG icons are rendered blurry on macOS, so adding bug #130678 as a dependency

> Just updated to Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8

> First build since tracking the blurry/poorly rendered icons on high dpi screens that I've seen the issue fixed.

Well, lucky you. I'm on Ubuntu 20.04, LO 6.4.2.2 (also tested this in Arch and Fedora 32) and SVG icons are still blurry like in barely-recognizable-blurry.

Created attachment 159915
Breeze SVG icons in HiDPI screen (LO 6.4.2.2 in Ubuntu 20.04/Arch/Fedora 32)

This is the typical chicken-egg problem: LO's SVG rasterizer / icons broken => default to PNG. Everybody uses PNG (and some complain about blocky icons in HiDPI) => nobody fixes the LO's SVG rasterizer / icons. Some more background info is in bug 133877 comment 11.

And OTOH people can manually select an SVG icon set, so the pressure to fix this isn't really high.

While the SVG icons easily look better when scaled, the PNG icons definitely look better in 100% / non-scaled in Linux.

And it also doesn't help that gtk3 always scales the rasterized icons, so you get the worse 100% SVG icons scaled to HiDPI.

In general I think people with high DPI screens would prefer to use SVG icons and live with or report a small number of bugs with a small number of mid-rendered icons then live with 100% of all icons being pixelated and ugly. Perhaps making the SVG renderer default only for high DPi users of SVG-compatible icon themes would make everyone happy: high DPI users get nicer icons overall, while devs get more user eyeballs (and bug reports, and potential contributors) using the SVG renderer.

FWIW all the icons look flawless to me with the Breeze SVG icon theme and a global 250% scale scale factor

(In reply to Jan-Marek Glogowski from comment #34)
> This is the typical chicken-egg problem: LO's SVG rasterizer / icons broken
> => default to PNG. Everybody uses PNG (and some complain about blocky icons
> in HiDPI) => nobody fixes the LO's SVG rasterizer / icons. Some more
> background info is in bug 133877 comment 11.

I totally agree on that, the main problem is the SVG Rasterizer (I guess that's the same as a SVG Renderer?). But there are plenty of free OpenSource SVG Renderers out there: Inkscape, Chromium, Firefox aso... all support SVG Rendering. Isn't it possible to use the code of those, if the LibO renderer is so hard to fix?

I know its easy to talk like that when you are not a developer, so just my two cents on that ;)

Just for your information. As an icon designer and mauntainer now all icon themes have SVG versions. So I would say its safe if in some point we reach perfect SVG support, than the PNG version can be removed or moved to the extension sites.

*** Bug 131946 has been marked as a duplicate of this bug. ***

In Debian Sid/unstable with GNOME 3.36.4 and LibreOffice 7.0.0, I switched the icon theme from *Elementary* to *Elementary (SVG)*, and the icons still look blurry on a HiDPI monitor connected over HDMI.

Created attachment 165049
Blurry Elementary SVG toolbar icons

Blurry SVG icons with LibreOffice 7.0.0.3 on Cinnamon 4.2.4 at resolution Cinnamon 4.2.4.

(In reply to moosetrax from comment #40)
> Created attachment 165049 [details]
> Blurry Elementary SVG toolbar icons
>
> Blurry SVG icons with LibreOffice 7.0.0.3 on Cinnamon 4.2.4 at resolution
> Cinnamon 4.2.4.

Editing to provide resolution information for previous comment: 3840x2160

Confirming blurry SVG (as well as PNG) icons.

Libreoffice 7.0.4.2
Ubuntu 20.04 Xfce4 4.16
4K-Screen@3840x2160
Xfce4 set to 2x window scaling

Probably helpful to narrow down this issue: In general, even PNG icons are rendered correctly with most applications (Firefox, Evolution, Pluma, all XFCE4 UI) - however, the same effect happens with Thunar, where replacing the XFCE4 icon theme with one using SVG also leads to blurry rendering.

Ok,time for an update here too :)
I use SVG-Icons quite a long time now, and for me those always look better than the png versions. I just did an comparison, and the png-version really looks terrible on an high-dpi monitor with 175% scale.

As far as I remember, SVG primarily was an issue on Linux? So can't we just make SVG default on Windows?

(In reply to bugzilla2 from comment #44)
> Ok,time for an update here too :)
> I use SVG-Icons quite a long time now, and for me those always look better
> than the png versions. I just did an comparison, and the png-version really
> looks terrible on an high-dpi monitor with 175% scale.
>
> As far as I remember, SVG primarily was an issue on Linux? So can't we just
> make SVG default on Windows?

Not at all!

There is no means currently to directly render the SVG into the GUI, meaning they will always be rendered to a bitmap and held in config (per user profile) for the display resolution in use. Look in %APPDATA%\LibreOffice\4\cache for the entire SVG icon theme rendered to PNG at scale. For performance the entire SVG of the active icon theme is parsed and the corresponding PNGs built on first launch.

The project deploys resolution appropriate 100% (so 96pdi) scaled PNG at three icon sizes small (sc 16x16) large (lc 24x24) and extra large (32 32x32). They are hand lay ups from the source SVG. They render correctly for most non-HDPI/non-scaledUI and remain appropriate for UI or os/DE scaling up to about 150%. They then start to look pixelated at 150% or above. Since 96-120dpi displays remains the norm for the vast majority of users there is no justification for doing more with the SVG.

Only if your os/DE is being scaled (as response to HiDPI, or by user setting) does it make sense to use SVG. Do it manually, the automated resampling and rendering of the SVG is inferior to the system deployed PNG at the default 100%, i.e. 96dpi resolution. The mechanism for "detection" of HiDPI (and so automated use of a resampled set of SVG icons)is "thresholded" at 168 dpi.

So just need to do it manually when UI is scaled >= 175%, the automated resampling and rendering of the SVG *remains* inferior to the project's deployed PNG at the default 100%, i.e. 96dpi resolution.

When and if the project can refactor to more effectively use the SVG icon sets, the real issue here, that will change.

I did some comparisons between png and svg and Stuart is right, up to 150% the png looks better then the svg. But over 150% scale, the svg looks dramatically better then the png. So can't we male SVG default when scale-factor is over 150%?

Sure we can say: "you can switch it manually in Preferences", but thats not "nice" for new Users that maybe have a first look into LibreOffice (because maybe they want to change from Microsoft Office) and then say: "oh my god, that looks terrible, not thanks, I'll stick to MSO. It may take years for those ppl to make another try, if ever.

And I do believe, that there are even many longterm LibreOffice Users, that might not know that they can "fix" ugly Icons on HiDPI Monitors by swichtching Icon-Sets...

And can you explain that sentence further:
"The mechanism for "detection" of HiDPI is "thresholded" at 168 dpi."
I'm not sure what that means.

(In reply to bugzilla2 from comment #47)
> And can you explain that sentence further:
> "The mechanism for "detection" of HiDPI is "thresholded" at 168 dpi."
> I'm not sure what that means.

See the source for CountDPIScaleFactor() [1]. It previously was a single threshold of >168dpi; and that got changed to a mix of dpi and scale factor for bug 100164 for non-macOS builds with [2]

So current thresholding is:

  nDPI > 216
     250 (so 2.5x)
  nDPI > 168
     200 (so 2.0x)
  nDPI > 120
     150 (so 1.5x)
  otherwise
     100 (or unscaled)

IIUC macOS passes usable dpi details, so does not need the mixed dpi & scale percentage.

Also the nDPI is not the actual hardware provided dpi, rather it is a calculated dpi that the os/DE is reporting--e.g. on Windows the Custom Scaling value, or with use of fractional scaling on your Linux DE.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx?a=true&r=1df81daa&h=924#919

[2] https://gerrit.libreoffice.org/c/core/+/30379/

Thanks for the explanation :)

That sounds not so bad, but LibO really should offer the same "steps" as the Host-OS (in my case Windows) does, that means 25% steps, not only 50% steps on Windows. Otherwise the Icons look to small or to big on 175% Scale for example. And not only the Icons itself, also the spaces between them (other bugs show that problem).

(In reply to bugzilla2 from comment #49)

So guess we would add additional bracketing for a 25% increment in scale factoring. Like this maybe:

 nDPI > 264
     300 (so 3.0x)
 nDPI > 240
     275 (so 2.75x)
 nDPI > 216
     250 (so 2.5x)
 nDPI > 192
     225 (so 2.25x)
 nDPI > 168
     200 (so 2.0x)
 nDPI > 144
     175 (so 1.75x)
 nDPI > 120
     150 (so 1.5x)
otherwise
     100 (or unscaled and using the prebuilt PNG)

@Tomaž -- what do you think. Looks easy hackable, but will the current SVG to PNG resampling suffice to generate usable icon themes at the 25% increments? And any other places in the UI that 25% increments would cause problems?

Just to remember this bug was happening also at 100% scale as you can see on the Ckmment below with an screenshot:

https://bugs.documentfoundation.org/show_bug.cgi?id=117158#c4

I cannot test anymore, because I switched back to MS Office.

(In reply to Renato S. Yamane from comment #51)
> Just to remember this bug was happening also at 100% scale as you can see on
> the Ckmment below with an screenshot:
>
> https://bugs.documentfoundation.org/show_bug.cgi?id=117158#c4
>
> I cannot test anymore, because I switched back to MS Office.

That was never confirmed and in the screen clips provided the LO icons are clearly not 100% or 150% of the native FHD mode--they've been scaled poorly.

The Yoga L380 in use does have a native screen DPI of ~165dpi, so believe it does scale the PNG icons to a higher scale--look in %APPDATA%\LibreOffice\4\cache\Colibre and if 150 shows the PNG rasters were scaled larger (with the pixilation noted).

To avoid similar on HiDPI displays close to this resolution, *simply* make a selection of an SVG based icon theme. Do not use the default PNG based icon theme.

Anyhow, the set of pre-installed non-SVG icon themes render cleanly from 100 to 150 pct scaling, starting to pixelate above 150 pct. If on a HiDPI display, or working at higher scaling 150 - 300% first use Tools -> Options -> View and switch to the bundled SVG icon sets which will then be resampled into clean PNG sized as needed.

A useful enhancement at this point might be to detect and switch from the PNG icon themes to SVG theme when at a higher scaling factor is in use--i.e. avoid scaling the PNG.

(In reply to V Stuart Foote from comment #50)
> (In reply to bugzilla2 from comment #49)
>
> So guess we would add additional bracketing for a 25% increment in scale
> factoring. Like this maybe:
>
> nDPI > 264
> 300 (so 3.0x)
> nDPI > 240
> 275 (so 2.75x)
> nDPI > 216
> 250 (so 2.5x)
> nDPI > 192
> 225 (so 2.25x)
> nDPI > 168
> 200 (so 2.0x)
> nDPI > 144
> 175 (so 1.75x)
> nDPI > 120
> 150 (so 1.5x)
> otherwise
> 100 (or unscaled and using the prebuilt PNG)
>
> @Tomaž -- what do you think. Looks easy hackable, but will the current SVG
> to PNG resampling suffice to generate usable icon themes at the 25%
> increments? And any other places in the UI that 25% increments would cause
> problems?

SVG icons shouldn't be a problem - if they are rendered properly.

FYI update: SVG icons on macOS have been fixed as per https://bugs.documentfoundation.org/show_bug.cgi?id=130678 which is a major milestone to move this enhancement request here forward.