Created attachment 189878 [details] Sample slide (PPTX) Opening the document there are two elements where transparency seems to be completely missing. This is a regression between Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 9c8a1994bea590db7436638580231daf31844fd6 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f8e591ab9182e0a61c4ae5b8f77b166fcaeaa877 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
Created attachment 189879 [details] Visual comparison Impress (left) vs PowerPoint (right)
Confirm with Bad in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b8ea553cf7f2fe5c913cb2b5e90d6d300b6be43 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Good in Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
c21a1c45e2403119c90af25cdb5350f978d5c93b is the first bad commit commit c21a1c45e2403119c90af25cdb5350f978d5c93b Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jul 25 09:06:10 2023 +0200 source 81994cb2b8b32453a92bcb011830fcb884f22ff3 source 81994cb2b8b32453a92bcb011830fcb884f22ff3 instdir/program/libchartcontrollerlo.so | Bin 3810384 -> 3810384 bytes instdir/program/libcppcanvaslo.so | Bin 382552 -> 382552 bytes instdir/program/libcuilo.so | Bin 5066680 -> 5066680 bytes instdir/program/libdrawinglayerlo.so | Bin 2067536 -> 2067632 bytes instdir/program/libeditenglo.so | Bin 3336888 -> 3336888 bytes instdir/program/libfrmlo.so | Bin 4274440 -> 4274400 bytes instdir/program/libmsfilterlo.so | Bin 1063760 -> 1063760 bytes instdir/program/libsclo.so | Bin 22502464 -> 22502464 bytes instdir/program/libsdlo.so | Bin 10531352 -> 10531352 bytes instdir/program/libsduilo.so | Bin 2135776 -> 2135776 bytes instdir/program/libsfxlo.so | Bin 7755888 -> 7755888 bytes instdir/program/libslideshowlo.so | Bin 2904968 -> 2905016 bytes instdir/program/libsmlo.so | Bin 2290704 -> 2290704 bytes instdir/program/libspllo.so | Bin 96136 -> 96136 bytes instdir/program/libsvtlo.so | Bin 3063720 -> 3063720 bytes instdir/program/libsvxcorelo.so | Bin 12298416 -> 12298464 bytes instdir/program/libsvxlo.so | Bin 5529544 -> 5529544 bytes instdir/program/libswlo.so | Bin 22729480 -> 22729480 bytes instdir/program/libswuilo.so | Bin 2985632 -> 2985640 bytes instdir/program/libtklo.so | Bin 7023960 -> 7024008 bytes instdir/program/libvclcanvaslo.so | Bin 1014736 -> 1014736 bytes instdir/program/libvcllo.so | Bin 20328320 -> 20332568 bytes instdir/program/libvclplug_gtk3lo.so | Bin 2748840 -> 2748840 bytes instdir/program/libvclplug_qt5lo.so | Bin 2495136 -> 2495032 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 26 files changed, 2 insertions(+), 2 deletions(-)
CC: Noel Grandin Noel, please, can you take a look? https://cgit.freedesktop.org/libreoffice/core/commit/?id=81994cb2b8b32453a92bcb011830fcb884f22ff3 author Noel Grandin <noelgrandin@gmail.com> 2021-04-16 20:33:10 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2023-07-25 08:38:12 +0200 commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 (patch) tree ae1750e92421ad2e0ec3f50351c3be6581841598 parent dabedcaf27b0af1e38a611b8d8e48444f848e01d (diff) 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 <plubius@neooffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I can also reproduce this in my local master build on macOS with Skia disabled: Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 9eb419b0b0f019f5fbc48ff1a11977e8b041edee CPU threads: 8; OS: macOS 14.0; UI render: default; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded It cannot reproduce it in LibreOffice 7.6.2.1 so I am fairly sure that we need to add or remove an AlphaMask::Invert() to adjust for the changes in the "transparency->alpha" patch. I starting looking for where the image is being drawn. A question for Linux users: if you check one or both of the Skia checkboxes (select the Tools > Options menu item and then select LibreOffice > View in the dialog that appears) and restart LibreOffice, do you see the same white background? With Skia/Metal and Skia/Raster on macOS, I see a barely visible transparent background instead of white.
Created attachment 189935 [details] Options - LibreOffice - View for 24.2 on Linux Thank you, Patrick. I tried disabling the Skia checkboxes as you suggested, alas these do not appear here on Linux (see screenshot and https://ask.libreoffice.org/t/there-is-not-skia-option/85326 ).
I managed to set Skia/Raster instead of default via Tools - Options... - LibreOffice - Advanced - Open Expert Configuration. No change compared to the original default setting.
I found that attachment 91446 [details] from bug 73247 is also affected by this issue
I have narrowed down the cause of this bug. It appears that the Effects > Glow > Radius setting in the Sidebar is what triggers this bug.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c3073c81223e9bf0f499d9fd3cfa8a7e8cb497a5 tdf#157502 and tdf#157652 invert 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.
Thank you, Patrick! Happy to confirm this as fixed with last nights build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ff9c8b62c1015972e9e89799832fa3690dcd46b4 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US (The second page of that document still is partly too bright in presentation mode, but that is bug #157558 already.)
I am rather worried that apparently the testsuite did not detect the large and varied number of cases the "transparency->alpha" change broke. @Xisco, is this something you may be able to help with (to prevent future regressions)?
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0cd5b97acbb3419eb7f550e39a291691373bd878 tdf#157502, tdf#157652: sd_png_export: Add unittest 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.