Issue On a brand new laptop (Acer Swift 5), resolution Full HD 1920*1080, Windows 10 1803 v17134.137, GPU intel UHD 620, default dpi factor 150%
I installed Libreoffice 22.214.171.124 x64, but the interface is awful : icons are very pixelated. I tried sevral tricks like deleting the cache, changing the dpi scaling method in Windows (Application : pixelated / System : Blurry ) and desactivated OpenGL with no success. I also tried SVG icons : they are a little bit better but still blurry.
I finally changed my system dpi to 125% and the interface is perfect (but my whole system is too small)
Steps to Reproduce:
1. Install Libreoffice (clean install on a new PC)
2. Launch Libreoffice / Writer with default dpi (150%) --> ICONS pixelated
3. Close Libreoffice
4. Change system dpi to 125%
5. Launch Libreoffice / Writer --> Icons are perfect
Icons pixelated (Screenshot to follow)
User Profile Reset: No
Created attachment 152836 [details]
Screenshot of pixelated interface
Windows update completed to windows 10 v1903 18362.239
Same behaviour with pixelated icons, no change.
Default 'Automatic' icon theme selection on Windows are the Colibre icons in PNG. The PNG will be scaled in bulk in response to setting os UI magnification.
That scaling of the PNG bitmaped icons can appear pixeleated at higher valuse--I find 175% to be ugly, %150 is marginal.
Fortunately to support scaling to support HiDPI displays, LibreOffice now provides icon themes as SVG. The SVG are scaled and then saved in bulk to new PNG corresponding to the UI magnification.
Give the SVGs a test from Tools -> Options -> View: 'Icon Style' droplist then close and reopen LibreOffice--a new SVG derived icon set will be built for the UI magnification set.
Unfortunately, I've already tried that with no succes. On last RC version 126.96.36.199, the icons (Colibre SVG) look strange and still very pixelated. See Screenshot attached
Created attachment 152990 [details]
with SVG icons, V188.8.131.52
[Automated Action] NeedInfo-To-Unconfirmed
*** Bug 131730 has been marked as a duplicate of this bug. ***
Still broken (both PNG and SVG) in 7 with skia BTW.
Created attachment 160587 [details]
SVG Sif icon lc_setoutline from LO cache folder
SVG theme icon from the cache folder as created by the LO icon rendering code. Badly aliased and exported at wrong size (25x25). SVGs should always be exported at power of two sizes to avoid aliasing, though aliasing isn't the only problem - see the following attachments for comparison.
Created attachment 160588 [details]
SVG Sif icon lc_setoutline exported using Inkscape at 25x25
Created attachment 160589 [details]
SVG Sif icon lc_setoutline properly exported using Inkscape at 24x24
Err s/power of two/divisible by two/g
Created attachment 160604 [details]
LO 7.0 on Win10 with Sifr svg icon theme scaled 250%
These reports are not a LO bug, rather are an os/DE issue with the Windows Display Manager for Windows.
MS Winodows mishandles the scaling using the percentage droplist from Display settings -> 'Change the size of text and apps, and other items'--taking the PNG (as rendered at 100% and then scaling).
As shown in attached, the UI is clean if correctly using Display settings -> 'Advance scaling settings', in this clip it is set to 250% with Sifr SVG
Also attaching the same lc_setoutline PNG icon (65px x 65px) generated from the SVG
IMHO => NAB when you use the os/DE correctly.
Created attachment 160605 [details]
lc_setoutline Sifr-svg at 250%
clean, crsip generation of PNG icon from SVG graphic with UI scaled 250%
I am comfortable closing this NotOurBug as the WDM os/DE does stupid things with the UI scaling (providing two different scaling routines).
Created attachment 160606 [details]
LO 7 Win Colibre-svg icon theme w WDM custom scale at 175%
(In reply to V Stuart Foote from comment #15)
> I am comfortable closing this NotOurBug as the WDM os/DE does stupid things
> with the UI scaling (providing two different scaling routines).
I'm not convinced it's OS thing.
First, I know that "Change the size of text and apps, and other items" thing *does* activate LO's HiDPI code, and LO has the DPI information from OS to handle the scaling itself. Since LO is HiDPI-aware application (its binaries have corresponding information in the manifests), Windows does not scale its UI itself.
Second, I tried the two different modes ("Change the size of text and apps, and other items" and "Advance scaling settings") on my Win10 1909, and both gave me exactly the same display as in OP's attachment 152836 [details] from comment 1.
(In reply to Mike Kaganski from comment #17)
> Second, I tried the two different modes ("Change the size of text and apps,
> and other items" and "Advance scaling settings") on my Win10 1909, and both
> gave me exactly the same display as in OP's attachment 152836 [details] from
> comment 1.
But did you change the Icon theme selection to an SVG theme first?
The PNG icon themes would be scaled poorly and be pixelated. Selecting an SVG theme, which would be parsed at initial launch, and the cleanly scaled icons saved as PNG for that scale level.
Please note that my example of badly rendered SVG icons was done at 100% scale - so no Windows scalling involved at all, it's LO that does bad job at rendering the icons (they are already blury in the cache folder). Also your examles are still aliased with burry outlines, though at the bigger sizes it is not so obvious.
(In reply to khagaroth from comment #19)
> Please note that my example of badly rendered SVG icons was done at 100%
> scale - so no Windows scalling involved at all, it's LO that does bad job at
> rendering the icons (they are already blury in the cache folder). Also your
> examles are still aliased with burry outlines, though at the bigger sizes it
> is not so obvious.
Icon sets can be found as zip archives in the installation folder share/config folders. Non-SVG icon themes have the icons pre-built as PNG at small 16px, large 24px, extralarge 36px, and a mix at higher res of 32, 48, 96 & 128px
The SVG themes are there also, but presently can not be used natively as SVG in the GUI (bug 115439). When selected enabled, the full SVG theme is extracted and rendered/resampled to PNG at the GUI resolution set. At 100% the lc_ large icons SVGs are converted to 25px PNG -- the resampled quality simply will not match the resolution of the PNGs packaged at that resolution.
Scaled SVG lc_ icon sizes as PNG after os/DE UI scaling:
These will be written to LO user cache  on creation, but are not refreshed except during an upgrade install (bug 128523). So if testing different icon themes and os/DE UI scaling, will need to clear the cache to force rebuild of the PNG icons.
 that is normally going to be AppData/Roaming/LibreOffice/4/cache for a full install. But with parallel installs it will be relative to the $ORIGIN path you set.
I did delete the cache folder when experimenting with it. As I said, the PNGs are already blurry like that in the cache, even at 100% scale.
Disabling OpenGL fixes that though. Disabling Skia in 7 does help as well. The SVG is then identical to the PNG version (at 100%, the scaled resolutions are a different matter). So a GPU code / shader bug?
Created attachment 161612 [details]
Comparison of icon rendering in LO 7 beta1 (all at 100%, no scaling)
Created attachment 161613 [details]
Comparison of icon rendering in LO 7 beta1 (175%)
(In reply to khagaroth from comment #23)
> Created attachment 161613 [details]
> Comparison of icon rendering in LO 7 beta1 (175%)
Yup, the 175% UI scale parses the SVG icons into a new PNG set--if a little smeared, while the scaled PNG gets pixelated--nothing unexpected.
Believe at 175% UI scaling, the SVG is scaled at 150%--next bump is 200% (for 200, 225%), and then 250% (for 250, 275% UI). So how does Win7 sp1 and you GPU drivers do with the UI at that scale--obviously the PNG would be junk, but with the SVG theme(s)?
The 175% case is what I would expect. It's the 100% case that is obviously seriously bugged when using Skia. And these icons aren't even the worst case, there are some icons that are barely visible because they are too thin and extremely blurry. And OpenGL on the current version is even worse.
(In reply to khagaroth from comment #25)
> The 175% case is what I would expect. It's the 100% case that is obviously
> seriously bugged when using Skia. And these icons aren't even the worst
> case, there are some icons that are barely visible because they are too thin
> and extremely blurry. And OpenGL on the current version is even worse.
DO NOT USE the SVG icons at scaling less than 150%, they are intended for HIDPI support or when users set a UI scaling > 175%--the PNG icons are intended for use through 150%.
Jmux on the ML (might be helpful to track down the issue):
"...So I tested the SVG icons at 100% and the cached PNG version of
breeze_svg/sw/res/emptypage_10x14.svg has the size 11x15 - yikes.
The SVG starts with: <svg viewBox="0 0 14 10" … which means x, y, width,
height. That is not pixel, but AFAIK the stretch related to the output size.
Looking into the problem, still hoping for a simple off-by-one error, I
ended in loadFromSvg
Somewhere in the bowels of XSvgParser::getDecomposition,
Primitive2DReference::getRange and XPrimitive2DRenderer::rasterize, all
the double precision handling eventually results in a rounding error, on
the basis of the bug report, which claims the 24px become 62px at 250%,
instead of 60px
P.S. "Fun" fact: all the dumped icon ranges / rectangles at 100% scale
start at -13.2292 -13.2292, while none of the values in the SVG are
negative. If you invert that (13.2292 13.2292), you get exactly the one
additional pixel: 13.2292 * 2 * 0.03937 (100th_mmToInch) * 96 (DPI) =
So actually I'm not that sure about the rounding error, but suspect some
signed error in XSvgParser::getDecomposition for the viewport. But that
might also be a red hering…"
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Looking at the text alignment toolbar buttons in Writer, they are blurry with Sifr SVG, Skia/Raster and 100% scaling.
With Sifr SVG, GDI and 150% scaling there is slight softness, but it's not really unpleasant.
Note for retesters: the design of Sifr icons was updated recently.
Version: 184.108.40.206.alpha0+ (x64) / LibreOffice Community
Build ID: 6d2363a553c9e275f9430510d70bc4b84e02aad8
CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded Jumbo
The fix for bug 151898 might improve things..
Richard, khagaroth and others: are you happy with what you see in the latest Win-x86_64@tb77-TDF build from https://dev-builds.libreoffice.org/daily/master/current.html ?