Description: The Colibre icons are broken and in black color on Surface Pro 4 with 2736x1824 resolution. Applying "System" high DPI scaling override fix the problem but the program would look blurry. Steps to Reproduce: 1.Set icons theme to Colibre Actual Results: Icons are broken and in black color. Expected Results: Icons are in normal colors. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 143849 [details] Broken icons in Colibre icon theme
Created attachment 143852 [details] Normal icon and blurry interface after applying "System" high DPI scaling override
I can confirm this issue on my machine, LibreOffice 6.1.0.3 64-bit on Windows 10 64-bit on a Surface Book 2 with 3000x2000 resolution and 200% scaring.
I also confirm this issue exists on my MSI GS60 with a 3840x2160 screen and 200% scaling under Windows 10 x64. Intel driver is 20.20.100.6194, which is the latest AFAIK. I cannot find the correct configuration to start LibreOffice on the discrete GPU Nvidia, not working from the Control Panel. So I'm not sure if this is GPU related. I switched to Breeze icon theme and looks OK but icons are pixelated.
*** Bug 119444 has been marked as a duplicate of this bug. ***
*** Bug 119536 has been marked as a duplicate of this bug. ***
How do you fix the issue though?
@Noel, Tomaž Any thoughts here, this looks to be alpha masking in loadFromSVG() in BitMapTools, scaled bitmaps generated when dpi crosses threshold, right? Somehow corrupted for Windows dwm.exe DE? Should this be duped to bug 114699...
(In reply to V Stuart Foote from comment #9) > @Noel, Tomaž > > Any thoughts here, this looks to be alpha masking in loadFromSVG() in > BitMapTools, scaled bitmaps generated when dpi crosses threshold, right? > Somehow corrupted for Windows dwm.exe DE? > > Should this be duped to bug 114699... Looking for the conversion, is the Fast bitmap scaling from the SVG stream the best mode to build the PNG cache? Would "BestQuality" or a specific algorithm do a better job with the Alpha channel and icon quality on Windows? =-ref-= https://opengrok.libreoffice.org/xref/core/vcl/source/image/ImplImageTree.cxx?a=true#181 https://gerrit.libreoffice.org/#/c/30339/ https://gerrit.libreoffice.org/#/c/47498/
I doubt this is about the specific scaling algorithm in use, although you are welcome to try the others. VCL has this weird notion is alpha is a separate kind of mask layer and I suspect that somewhere the layer is being treated as a real mask instead of as alpha.
*** Bug 119618 has been marked as a duplicate of this bug. ***
All the icon themes except Sifr seem to be corrupted on second and subsequent launches after changing to that icon theme. For users impacted by this bug, that want a quick fix until resolved, go to Tools -> Options, then in Options go to LibreOffce -> View, then set Icon Style to Sifr (Sifr Dark has the same corruption issues, you must use Sifr). Maybe the devs can also use the knowledge that the Sifr icons do not suffer the corruption as a starting point to track down the bug.
Checking with a Windows Surface Pro 4, at full 2736 x 1824px resolution ~275ppi and 200% UI scaling the icons are corrupted--Alpha channel incorrectly treated as a mask as Noel suggests? But same hardware, with screen resolution reduced to 1680 x 1050px ~165ppi and 100% UI scaling--all icon themes render cleanly. Same hardware at 1680 x 1050px ~165ppi, set UI scaling to 150%. The icon theme corruption occurs. At UI scaling of 125% (so the 32px PNG are used, right?), no corruption. So, not the absolute ppi value of the hardware, or as set from the DE. Rather, issue here seems to be any scaling/reparsing for any icon theme cache being pulled from SVG. Guess the Sifr icons are just not affected by an alpha channel based mask.
Testing a bit further, Desktop PC with nVidia GPU and 24" 1920 x 1200 ~96ppi monitor. Reducing DE resolution to 1280 x 768 ~62.2ppi, at 125% scaling no issue. But at 150% scaling via DE the icon theme corruption is present. All pointing to issue when scaling the SVG icon themes kicks in--not the hardware or higher ppi values present in HiDPI.
Hi this bug frustrate me. Is there any change to fix this issue from a design point of view? Should I add 48px icons? I would really like to fix this issue but I don't know one with hidpi screen.
(In reply to andreas_k from comment #16) > Hi this bug frustrate me. Is there any change to fix this issue from a > design point of view? > > Should I add 48px icons? I would really like to fix this issue but I don't > know one with hidpi screen. I don't think so, fill-opacity is too viable a feature of SVG. Would think we have to fix the scaling mishandling. Thus far this has only been on Windows, not clear if macOS or the Linux compositors are affected in the same way.
removing the HiDPI block--as this affects any resolution hardware where the Windows DE UI is being scaled > 150%
*** Bug 114699 has been marked as a duplicate of this bug. ***
*** Bug 115914 has been marked as a duplicate of this bug. ***
*** Bug 117674 has been marked as a duplicate of this bug. ***
originated with work on bug 51733 and tweaks to support use of scaled SVG icons to rebuild icon cache. https://gerrit.libreoffice.org/#/c/30339/ https://gerrit.libreoffice.org/#/c/47498/
*** Bug 120524 has been marked as a duplicate of this bug. ***
I tried to reproduce this. So I'm on: Version: 6.2.0.0.alpha1+ Build-ID: 8043727a5882d7cc7904a79ded6c989a18b8c67a CPU-Threads: 10; BS: Windows 6.1; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); Calc: threaded That is a Windows 7 running in a Linux KVM, no OpenGL available. I also packaged the SVG Collibre images, which is the default icon set in Windows. I changed my scaling in Windows to 150%. I also tested LO 6.1.3 + 6.0.6 with the default LO icon themes. For all variants I started LO three times and then cleaned the icon cache. I never found a broken icon. It's normal that icons become pixelated, as LO just scales PNGs to match your scaling factor, if you don't have an SVG icon set. The scaled icons are in %appdata%\LibreOffice\4\cache\<your icon theme>\<your scale>. So the first thing - to get an idea what is going on - is to check this cache. 1. So please update to the latest supported minor version, which would be either 6.1.3 or 6.0.6. 2. Then remove the icon cache: %appdata%\LibreOffice\4\cache\ 3. Open LO a few times. If you can still reproduce the problem, please attach one of the broken icons from the cache directory to the report. The attached image doesn't look like an alpha problem, more like a wrong color palette problem, where RGB values are somehow interpreted like BGR. Strange. And please copy the selectable info from Help >> About LibreOffice (Ctrl+A + Ctrl+C works on this dialog). Then change the status of this ticket back to NEW.
Created attachment 146011 [details] lo master / 6.2.0 on Windows 10 on HD display reduced to 1366x768 with UI scaling 175%
Created attachment 146012 [details] icon cache Colibre from 150 framework -- Win10 on full HD display resized 1366x768 and UI scale 175% (In reply to Jan-Marek Glogowski from comment #24) > ... > If you can still reproduce the problem, please attach one of the broken > icons from the cache directory to the report. The attached image doesn't > look like an alpha problem, more like a wrong color palette problem, where > RGB values are somehow interpreted like BGR. Strange. > > And please copy the selectable info from Help >> About LibreOffice (Ctrl+A + > Ctrl+C works on this dialog). > > Then change the status of this ticket back to NEW Able to reliably reproduce on Windows 10 laptop: 1. reset display from 1920 x 1080 to 1366 x 768 2. set display properties to 175% scale factor (requires logoff/logon) 3. open lo 4. options -> view -> icon style, reset 5. close lo 6. launch lo 7. repeat 4 changing icon style selection 8. repeat 5, 6 7 9. option -> view -> icon style, reuse Colibre (have to cycle to ensure the cache is rebuilt) 10. open writer, close 11. open writer Attached here is a zip of the cache\colibre\150\framework\res resulting from scaling UI to 175% on the ressized 1366x768 Windows 10 DE. Also included are results of ImageMagick identify -verbose for each of the corrupt PNG.
I think we did it wrong on hidpi cause I get way to much bug reports. Would it be possible to change the icon size on hidpi instead of scale png files? Eg. We have sc_ 16*16 px icons for menubar, lc_ 24*24 px for toolbar. Can libo use lc_ icons on menubars and the 32px icons for toolbars? Than we dont have to scale png files. We can use them with 100%.
(In reply to andreas_k from comment #27) > I think we did it wrong on hidpi cause I get way to much bug reports. > > Would it be possible to change the icon size on hidpi instead of scale png > files? > > Eg. We have sc_ 16*16 px icons for menubar, lc_ 24*24 px for toolbar. Can > libo use lc_ icons on menubars and the 32px icons for toolbars? Than we dont > have to scale png files. We can use them with 100%. I don't think we are at that point, and frankly a 32px icon does not satisfy the requirement for HiDPI displays, need at least 64px or higher to be readable, so scalling SVG remains necessary. Also, I don't think we'd want to revert to PNG based that as it moves us the wrong direction. For bug 51733 we implemented support for SVG based icons, and with bug 115439 we want to make them the preferred over packaging PNG icons. Also, SVG based delivery is the only way to support dynamic recolor of icons in response to DE theme (i.e. to recolor the sifr light or dark theme icons). So, I thnink we need to keep at it and get the sRGB color, and Alpha channel of the loadFromSVG() scaling to PNG working correctly, and tweak any of the icon sets missing the SVG flavor image. @Tomaž, any comment?
From the icon designers you get an go for svg cause our life is with svg only easier.
So I can't set an other scaling then 100, 125, 150 and 200% in Win7. Only 150 or 200 produce cached icons. None of them produces broken icons for me. Can you check, if changing options -> view -> OpenGL and HW accel changes something in the result? Maybe it's driver related, but I can't imagine why it should. Even the broken icon look correct, except for the colors. But these doesn't look like a simple mistake of a shift or color swap. At least I couldn't identify any pattern staring at the pixel RBGA values.
(In reply to Jan-Marek Glogowski from comment #30) > So I can't set an other scaling then 100, 125, 150 and 200% in Win7. > Only 150 or 200 produce cached icons. > None of them produces broken icons for me. > > Can you check, if changing > > options -> view -> OpenGL and HW accel > > changes something in the result? > Maybe it's driver related, but I can't imagine why it should. > > Even the broken icon look correct, except for the colors. But these doesn't > look like a simple mistake of a shift or color swap. At least I couldn't > identify any pattern staring at the pixel RBGA values. Fired up a Windows 7 sp1 VM on VMWare on a 1920x1200px monitor. Forced the VM to 1366x768 and used "Set custom text size" first to 175%, then to 200% -- with this non-OpenGL/non-64bit build I was not able to produce the corrupted icons as above. Icons recorded into cache\colibre\150 or cache\colibre\200 respective for 175% or 200% were cleanly rendered. As were scaled icons for tango, breeze, karasa_jaga and sifr at those resolutions. Will do a test of non-VM default rendering with 64-bit build--but pretty sure I was seeing the corrupt icons on Windows 10 boxes both default (non-OpenGL) rendering and with OpenGL rendering. =-testing-= Windows 7 SP1 on VMWare Workstation Pro 14.1.1 VMWare SVGA 3d Graphics with Version: 6.2.0.0.alpha1+ Build ID: 96cf06c947838120e37f3fbb4d0543dd882cb20c CPU threads: 1; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-25_22:57:51 Locale: en-US (en_US); Calc: threaded
(In reply to V Stuart Foote from comment #31) > (In reply to Jan-Marek Glogowski from comment #30) So on Windows 10 Home 64-bit (1709) en-US on a MS Surface 4 with Intel Iris Graphics 540 Driver Version 21.20.16.4627 at 2736 x 1824 px Version: 6.2.0.0.alpha1+ (x64) Build ID: fd855967e0474323e22c9d27152d271826a43821 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2018-10-28_02:40:36 Locale: en-US (en_US); Calc: threaded With default rendering, no corruption cycling through the icon styles. But with OpenGL rendering enabled, the scaled icons loaded to cache suffer the color/alpha corruption in the 200 folders. Not sure what to make of it, but it seems to be an OpenGL related dependency.
Created attachment 146112 [details] cache 200 for Colibre and Tango with OpenGL rendering (In reply to V Stuart Foote from comment #32) attached are the full cache 200 for Collibre and Tango from OpenGL--numerous scaled sc_ (at 36x36), lc_ (at 48x48) and res & framework (at 64x64) icons show corrupted colors.
After your OpenGL comment I've started reading the scaling codepath on Windows. When OpenGL is available it is used to scale bitmaps. LO reads the PNG, then copies the data to a texture, scales the texture, uses this texture for painting and copies the texture's data to write the PNG. As far as I understand the bug report, the first time the scaled icons are correct, so I assume the error happens when copying the texture data to the bitmap to write the scaled PNG. Just to be sure: can you check if the icons written at the first start are already corrupt, despite LO looking correct? So my guess is the texture fetching code is wrong (OpenGLSalBitmap::ReadTexture). My main problem is that I don't have Windows with OpenGL, so I can just blindly guess a fix. I don't think that is a useable bugfixing environment.
(In reply to Jan-Marek Glogowski from comment #34) > ... > Just to be sure: can you check if the icons written at the first start are > already corrupt, despite LO looking correct? > ... Yes, able to confirm that by starting the UI once, prior to adjusting the scale factor for Windows 10 DE, and setting Icon theme to other than Colibre (Automatic). Then when rescaled, on launch and change of Options -> View -> Icon theme to Colibre (Automatic) the UI appears correct. But the cache/colibre/200/cmd created already has corrupted PNG--both the lc_, and then the sc_ icons if Toolbar Icon Size is set "small". Icons in UI appear correctly, until cycling through the Icon themes and back to Colibre (Automatic). Also, no corruption noted doing the same steps but with Default CPU/HA rendering.
There is now a patch in Gerrit. If someone here has a Windows build, you can try it. The patch isn't Windows specific and much simpler then my original idea. Due to Jenkins infrastructure problems I didn't push it yet. https://gerrit.libreoffice.org/#/c/62505/
(In reply to Jan-Marek Glogowski from comment #36) So, not an SVG icon handling issue. Does this mean we *never* pick up SVG flavors of icons in the Windows builds for the HiDPI handling noted comment 10? And it is only lower res 8-bit color PNG that are being scaled and corrupted? Are the SVG being scaled and pushed to cache as PNG for HiDPI, but then not reused? If so where do they go? > There is now a patch in Gerrit. If someone here has a Windows build, you can > try it. The patch isn't Windows specific and much simpler then my original > idea. Due to Jenkins infrastructure problems I didn't push it yet. > Will look for it to roll to nightlies once pushed.
(In reply to V Stuart Foote from comment #37) > Does this mean we *never* pick up SVG flavors of icons in the Windows builds > for the HiDPI handling noted comment 10? And it is only lower res 8-bit > color PNG that are being scaled and corrupted? SVG icons aren't packaged anywhere yet and they are meant to be separate icon themes (breeze_svg, colibre_svg,..) until we decide to drop the PNG icon themes. > Are the SVG being scaled and pushed to cache as PNG for HiDPI, but then not > reused? If so where do they go? SVG icons are all cached as PNG (and rendered at higher resolution for HiDPI and not scaled), however PNG icons are only cached for the HiDPI and "disabled" variants.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b0c475a00ced9ec1e4ef1efb9d184ee8e2a3eaab%5E%21 tdf#119020 always scale icons as 24bit RGB It will be available in 6.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So I couldn't actually test the fix. Got some minimal review so lets see, if it fixes the bug for users, who can reproduce it. Actually icon quality might even improve, as this simply converts all icons to 24bit + alpha before scaling them.
On Windows 10 Pro 64-bit (1803) en-US with nVidia GTX 750ti with 3840x2160 40" (~110.15 dpi) Version: 6.2.0.0.alpha1+ Build ID: 4fa9e6f7f891b335ae1b432e0848c1e46c8fe3ef CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-30_22:44:48 Locale: en-US (en_US); Calc: CL With OpenGL rendering enabled and scaling UI to 300% to force LO icon scaling--all of the icon themes scale cleanly if a bit pixelated but without any color corruption. Will check a 64-bit build (TB42 or TB62) when one rolls. @Jan-Marek, Tomaž -- notice we've been using the "BMPScaleFlag::Fast" [1], any reason not to use Lanczos or at least BiCubic to reduce pixelation since these scaled icon themes are being cached to user profile on first launch? Better at least until SVG themes can be finished. And assuming 64-bit also is also good, can this be back ported for 6.1.4? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/source/image/ImplImageTree.cxx#187
(In reply to V Stuart Foote from comment #41) > any reason not to use Lanczos or at least BiCubic to reduce pixelation Or the corresponding enum for BmpScaleFlag [1] since the OpenGL texture rendering of the bitmap (now 24bit as here) also looks to use it in its Scale method [2]. Would the type of scaling of the icon theme cost that much CPU/GPU overhead in parsing the PNG bitmaps into better quality bitmaps? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/include/vcl/bitmap.hxx#47 [2] https://opengrok.libreoffice.org/xref/core/vcl/inc/opengl/salbmp.hxx#78
(In reply to V Stuart Foote from comment #41) > On Windows 10 Pro 64-bit (1803) en-US with nVidia GTX 750ti with 3840x2160 > 40" (~110.15 dpi) > Version: 6.2.0.0.alpha1+ > Build ID: 4fa9e6f7f891b335ae1b432e0848c1e46c8fe3ef > CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86@42, Branch:master, Time: 2018-10-30_22:44:48 > Locale: en-US (en_US); Calc: CL > > With OpenGL rendering enabled and scaling UI to 300% to force LO icon > scaling--all of the icon themes scale cleanly if a bit pixelated but without > any color corruption. Will check a 64-bit build (TB42 or TB62) when one > rolls. Ok. Just set the bug to resolved - verified. I assume there is no difference, otherwise the problem is totally different and would need an extra bug IMHO. > @Jan-Marek, Tomaž -- notice we've been using the "BMPScaleFlag::Fast" [1], > any reason not to use Lanczos or at least BiCubic to reduce pixelation since > these scaled icon themes are being cached to user profile on first launch? > Better at least until SVG themes can be finished. We can change the scaling from ::Fast to ::Default or ::BestQuality. No idea how much this would prolong the first start. So I'm a bit reluctant to just change the value, as I can see the bug reports coming in that LO startup time has increased. Unless we implement scaling as a completely asynchronous background job, which can dynamically update any images (which would also be cool to have for document open times with many images of any kind, which need scaling for zoom level, also PDF or SVG). Eventuality it would also be good to convert all icons as a background job and store them in a zip again. That should still be faster then a single file access, even with unzip, then all those small files. But both ideas are a whole new story and the 2nd depends on the 1st. > And assuming 64-bit also is also good, can this be back ported for 6.1.4? I'll do backports for 6.1 and 6.0, even if 64bit still has problems, as it definitely solves them for 32bit. 6.0.7 is due this week / Thursday I think, so no more time left for 6.0. It's simple enough to get accepted this late IMHO.
> how much this would prolong the first start. So I'm a bit reluctant to just > change the value, as I can see the bug reports coming in that LO startup > time has increased. Since this would only slow down the first start with a new Icon Set, that would be acceptable in my opinion. If Icon quality increases thats the way LibO should go. Of course I would mention such a change in the NEWS for that release... > Unless we implement scaling as a completely asynchronous background job, > which can dynamically update any images (which would also be cool to have > for document open times with many images of any kind, which need scaling for > zoom level, also PDF or SVG). Sounds great :) But until then, a one time only slower start should be fully acceptable to users.
*** Bug 121079 has been marked as a duplicate of this bug. ***
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-1": https://git.libreoffice.org/core/+/47789c45dfc7ba8509eedab37f1dbd70ea79da41%5E%21 tdf#119020 always scale icons as 24bit RGB It will be available in 6.1.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks good in the 64-bit builds as well, HiDPI and scaled UI in "normal" ~96dpi screen. Version: 6.2.0.0.alpha1+ (x64) Build ID: e33424dd887cb1a11a3dba2513ef0f4bf93a6dbe CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-01_00:43:29 Locale: en-US (en_US); Calc: CL
*** Bug 121357 has been marked as a duplicate of this bug. ***
*** Bug 121653 has been marked as a duplicate of this bug. ***
*** Bug 121730 has been marked as a duplicate of this bug. ***
*** Bug 121960 has been marked as a duplicate of this bug. ***
*** Bug 121998 has been marked as a duplicate of this bug. ***
*** Bug 108526 has been marked as a duplicate of this bug. ***
Hi, I was affected by this bug on fresh installation of 6.1.3. Installing 6.1.4 indeed fixed my issue, but only after deleting my C:\Users\foo\AppData\Roaming\LibreOffice and restarting LibreOffice. I tried to reboot before but did not help. If I am not alone, this means that users won't see that the issue is fixed. Regards, Yvan
(In reply to yvan from comment #54) > I was affected by this bug on fresh installation of 6.1.3. Installing 6.1.4 > indeed fixed my issue, but only after deleting my > C:\Users\foo\AppData\Roaming\LibreOffice and restarting LibreOffice. I tried > to reboot before but did not help. Yup the scaled, broken icons are cached. No real way to tell if they are wrong, without a lot more coding effort. It's enough to delete the %appdata%\LibreOffice\4\cache\<your icon theme name> folders. > If I am not alone, this means that users won't see that the issue is fixed. ?
Yes, deleting the cache folder is enough to fix it, and deleting the cache folder of a user not having the issue seems to have no negative effects except a few extra milliseconds next launch. However, most users who aren't tech inclined aren't going to know to delete the cache folder to fix their icons. Maybe the 6.2.0 installer/updater can have a one-time delete cache folder routine, so everyone starts fresh?
*** Bug 122230 has been marked as a duplicate of this bug. ***
*** Bug 122986 has been marked as a duplicate of this bug. ***
*** Bug 123239 has been marked as a duplicate of this bug. ***
*** Bug 123717 has been marked as a duplicate of this bug. ***
*** Bug 123932 has been marked as a duplicate of this bug. ***
(In reply to Robert Berg from comment #56) > Maybe the 6.2.0 installer/updater can have a one-time delete cache > folder routine, so everyone starts fresh? I am running LibreOffice 6.3.1 after numerous updates from 5.x onwards and have had terrible blacked-out icons for months despite those updates until I found this fix. Please implement this in the Windows installer, I created bug 128523.