Description: 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 6.2.5.2 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 Actual Results: Icons pixelated (Screenshot to follow) Expected Results: Icons sharp Reproducible: Always User Profile Reset: No Additional Info:
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 6.3.0.2, the icons (Colibre SVG) look strange and still very pixelated. See Screenshot attached
Created attachment 152990 [details] with SVG icons, V6.3.0.2
[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). @Tomaž, Mike?
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: 100% 25px 150% 37px 200% 50px 250% 62px These will be written to LO user cache [1] 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. =-ref-= [1] 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) = 99.99936 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…"
Dear Richard, 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! Warm Regards, QA Team MassPing-UntouchedBug
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: 7.5.0.0.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 ?