Created attachment 188791 [details] Screenshot with kf5 VCL plugin on Linux Steps to reproduce: 1) start LO Writer on Windows or on Linux with kf5 or gen VCL plugin 2) open the "Properties" deck in the sidebar 3) look at the "Font Color" and "Character Highlighting Color" buttons Actual result: They have a white background (s. screenshot) Expected result: They should have the same background as the surrounding area of the sidebar (light grey with Breeze theme with kf5).
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed5d9496320d78032ab4a65fc5547aad069d19f2 CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Self-confirming, since Telesto also mentioned this in tdf#155912 comment 40. This starts at commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Author: Noel Grandin Date: Fri Apr 16 20:33:10 2021 +0200 Convert internal vcl bitmap formats transparency->alpha (II) (Second attempt at landing this) Image formats and graphics APIs use alpha, not transparency, so change our internal formats and data structures to work directly with alpha, so we don't need to modify data before we push it to graphics APIs. Add a couple of new Color constants to make the intention of the vcl code clearer. Notes (*) On macOS, tweaking the logic in CreateWithSalBitmapAndMask to more accurately reflect the requirements of the CGImageCreateWithMask function seems to fix some tests. (*) The vcl code does not properly support gradients with transparency. So the previous code was wrong, and this change is going to result in slightly different wrongness. Change-Id: I9e21c2e98d88ecfdc5f75db13bd1ffff7c38db98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114168 Tested-by: Jenkins Reviewed-by: Patrick Luby Reviewed-by: Noel Grandin
(In reply to Michael Weghorn from comment #1) > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: ed5d9496320d78032ab4a65fc5547aad069d19f2 > CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: gtk3 > Locale: en-GB (en_GB.UTF-8); UI: en-US > Calc: threaded Sorry, the gtk3 VCL plugin is the variant/version where it does *not* appear, but the same version with gen or kf5 shows the issue: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed5d9496320d78032ab4a65fc5547aad069d19f2 CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
fix here https://gerrit.libreoffice.org/c/core/+/155425
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f69a98d1175720db3b1ce5f5ae2c7fc0fc35a2b2 tdf#156629 Font,highlighting color buttons in sidebar have white background... It will be available in 24.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.
Created attachment 188831 [details] Scaling of font icons with Skia/Metal on macOS
(In reply to Patrick Luby from comment #5) > Created attachment 188831 [details] > Scaling of font icons with Skia/Metal on macOS I just built master with the commit on macOS and the bug is fixed with Skia/Raster and Skia disabled. However, with Skia/Metal, the icon's bitmap is getting scaled significantly larger. This scaling is very similar to the scaling I am seeing with only Skia/Raster in https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15. Is anyone else seeing this scaling? Or is this a macOS bug that I have found?
(In reply to Patrick Luby from comment #5) > Created attachment 188831 [details] > Scaling of font icons with Skia/Metal on macOS That looks like either (a) the icon is being scaled too large or (b) the icon is scaled, but is then drawn back to the output buffer at the wrong size
(In reply to Noel Grandin from comment #7) > (In reply to Patrick Luby from comment #5) > > Created attachment 188831 [details] > > Scaling of font icons with Skia/Metal on macOS > > That looks like either > > (a) the icon is being scaled too large > > or > > (b) the icon is scaled, but is then drawn back to the output buffer at the > wrong size What I find difficult to debug is that the scaling only happens with one Skia setting and not the other and worse, in these two case its one or the other but never both. Last night I went through the vcl code and flipped all the RenderRaster conditionals that I could find to debug https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15 but so no change. I repeatedly this flipping this morning and no change for this bug either. Are you not seeing this behavior on Windows or Linux with Skia/Vulcan? Also, are you not seeing https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15?
(In reply to Patrick Luby from comment #8) > Are you not seeing this behavior on Windows or Linux with Skia/Vulcan? I do not see rendering artifacts on Windows, cannot test Linux. > Also, > are you not seeing > https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15? On Windows, I see rendering artifacts near the tail.
(In reply to Noel Grandin from comment #9) > (In reply to Patrick Luby from comment #8) > > Are you not seeing this behavior on Windows or Linux with Skia/Vulcan? > > I do not see rendering artifacts on Windows, cannot test Linux. > > > Also, > > are you not seeing > > https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15? > > On Windows, I see rendering artifacts near the tail. I now think that this is a macOS-only bug. If the bug was occurring on Windows, you would see the 2x scale gray outline of the elephant in the bottom half of the animated image like in https://bugs.documentfoundation.org/attachment.cgi?id=188832. I forced the native and Skia window scale to always be 1.0f in getWindowScaling() in vcl/skia/osx/gdiimpl.cxx and this Skia/Raster scaling behavior no longer occurs for this bug or for https://bugs.documentfoundation.org/show_bug.cgi?id=156630 so I suspect that Skia's window scale is diverging from the native window scale. I'll investigate that and submit a separate Gerrit change when I have a fix.
Maybe the same thing is happening here? (bug 156686)
(In reply to Commit Notification from comment #4) > However, with Skia/Metal, the icon's bitmap is getting scaled significantly > larger. > > This scaling is very similar to the scaling I am seeing with only > Skia/Raster in > https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c15. > > Is anyone else seeing this scaling? Or is this a macOS bug that I have found? Don't see this on Linux.
Fix verified with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d1d07992a89ba503f1d457a8f79926063f4d3f9c CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Rafael Lima from comment #11) > Maybe the same thing is happening here? (bug 156686) Might be something similar, at least it's a regression from the same commit. I commented there.
(In reply to Patrick Luby from comment #10) > I now think that this is a macOS-only bug. If the bug was occurring on > Windows, you would see the 2x scale gray outline of the elephant in the > bottom half of the animated image like in > https://bugs.documentfoundation.org/attachment.cgi?id=188832. > > I forced the native and Skia window scale to always be 1.0f in > getWindowScaling() in vcl/skia/osx/gdiimpl.cxx and this Skia/Raster scaling > behavior no longer occurs for this bug or for > https://bugs.documentfoundation.org/show_bug.cgi?id=156630 so I suspect that > Skia's window scale is diverging from the native window scale. > > I'll investigate that and submit a separate Gerrit change when I have a fix. I now suspect that this is a "Skia + window scale is > 1.0" bug. I fixed a similar case by forcing the alpha mask to be rendered to a bitmap buffer before constructing a new BitmapEx with it. Maybe we need the same type of fix for this case?: https://gerrit.libreoffice.org/c/core/+/155429/4/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx
(In reply to Patrick Luby from comment #15) > I now suspect that this is a "Skia + window scale is > 1.0" bug. I fixed a > similar case by forcing the alpha mask to be rendered to a bitmap buffer > before constructing a new BitmapEx with it. Maybe we need the same type of > fix for this case?: Update: I have a fix for this in the following patch: https://gerrit.libreoffice.org/c/core/+/155562
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ce2d9f5dd4b6a26847c4779bce4866d969ff4400 Related tdf#156629 force snapshot of alpha mask It will be available in 24.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/926c5246b6694d469a6caed5d7ea4c3a68648468 Related tdf#156630 and tdf#156629 force snapshot of alpha mask It will be available in 24.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5baac4e53128d3c0fc73b9918dc9a9c2777ace08 Reimplement fix for tdf#156629 and tdf#156630 It will be available in 24.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.