Created attachment 192332 [details] Area fill with transparency and without Draw a custom shape e.g. from category "Basic shapes". Use for its fill an image, which has transparent parts. Apply "Toggle extrusion" to the shape. Notice that the fill is totally wrong rendered. The attached document has a rectangle with a rose with transparent parts as area fill and a second rectangle with a cat without transparency. Toggle extrusion on and off the see the problem. Expected: The transparent parts remain transparent in extrusion mode.
The transparency was correct in Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 32; OS: Windows 6.19; UI render: default; Locale: de-DE (de_DE); Calc: group Because this simple extrusion fill shifts the image from front to back you see the rose two times. Nevertheless using an image fill is useful to get a 3D-rotated image. Use a small extrusion depth e.g 1mm.
It was OK in Version: 6.5.0.0.alpha0+ (x64) Build ID: 147af9e2cf7f937ed83ab00574b6a418a2cb629e CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
Created attachment 192381 [details] Extrusion with true 3DScene There error affects true 3D-scenes too, see attachment. It is OK in Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded The problem is not related to Skia.
The error is visible too in Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
From the versions I have locally available the last good one is from about 2023-07-25 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 42f0422d19c4d0a2fb09654fb6d1d92e50f6dd5c CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded and the first bad on is from about 2023-08-10 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded I hope it helps to bibisect it.
Repro in: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded No repro in: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Bibisected to the following commit, using repo bibisect-linux-64-24.2. Adding CC: to Noel Grandin. 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 Convert internal vcl bitmap formats transparency->alpha (II)
(Actually adding Noel to CC. Thanks Aron for the bisect.)
(In reply to Aron Budea from comment #7) > Bibisected to the following commit, using repo bibisect-linux-64-24.2. : > Convert internal vcl bitmap formats transparency->alpha (II) Patrick Luby heroically fixed tons of regressions cause by that change last year; copying for potential advice.
I can reproduce this as well. It looks like an inverted alpha mask to me. When I get some time, I'll see if I can locate where the alpha mask is created for the two attachments. Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 833abb4a197561c34ec59cceb9d7d8a46f6b17ce CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 192809 [details] Stack trace where extruded shapes alpha mask is created
(In reply to Patrick Luby from comment #11) > Created attachment 192809 [details] > Stack trace where extruded shapes alpha mask is created I have done some debugging and I narrowed down where in the code the bug is occurring. Using the following debug patch, the roses in the two attached sample documents render correctly, but the debug patch makes the cat photo in attachment #192332 [details] completely transparent. So, I am guessing that the alpha channel needs to be inverted higher up the stack in attachment #192809 [details]: diff --git a/drawinglayer/source/processor3d/zbufferprocessor3d.cxx b/drawinglayer/source/processor3d/zbufferprocessor3d.cxx index b9cb8ffb7a1d..2f24b916e587 100644 --- a/drawinglayer/source/processor3d/zbufferprocessor3d.cxx +++ b/drawinglayer/source/processor3d/zbufferprocessor3d.cxx @@ -302,7 +302,8 @@ void ZBufferRasterConverter3D::processLineSpan(const basegfx::RasterConversionLi if(nNewZ > rOldZ) { // detect color and opacity for this pixel - const sal_uInt16 nOpacity(std::max(sal_Int16(0), static_cast< sal_Int16 >(decideColorAndOpacity(aNewColor) * 255.0))); + // try inverting the opacity value + const sal_uInt16 nOpacity(255 - std::max(sal_Int16(0), static_cast< sal_Int16 >(decideColorAndOpacity(aNewColor) * 255.0))); if(nOpacity > 0) {
OK. The stack traces to my debug patch are nearly identical except that the cat photo in attachment #192332 [details] goes through the GroupPrimitive2D class. That seems reasonable so maybe the inverted alpha channel happens at document load or change. Not sure where to look for that: frame #20: 0x0000000111a99a34 libdrawinglayerlo.dylib`drawinglayer::primitive2d::GroupPrimitive2D::getChildren(this=0x00006000057af480, rVisitor=0x0000600005f90f50) const at groupprimitive2d.hxx:76:90 frame #21: 0x0000000111ad5e60 libdrawinglayerlo.dylib`drawinglayer::primitive2d::GroupPrimitive2D::get2DDecomposition(this=0x00006000057af480, rVisitor=0x0000600005f90f50, (null)=0x0000600005f90f58) const at groupprimitive2d.cxx:53:13 frame #22: 0x0000000111b576c4 libdrawinglayerlo.dylib`drawinglayer::processor2d::BaseProcessor2D::process(this=0x0000600005f90f50, rCandidate=0x00006000057af480) at baseprocessor2d.cxx:46:24
One more detail: I unzipped both of the attached sample documents and opened the .png files within the documents in LibreOffice. All render correctly so I suspect that alpha inversion of the rose image is occurring when the extrusion process copies the loaded .png data. Not sure if that helps.
When this bug is fixed, the patch for the blocked bug 159912 has to be adapted. For details how to do that see the comment there.
I think I have fixed this bug in the following patch: https://gerrit.libreoffice.org/c/core/+/164322 @Regina Your fix for tdf#159912 looks like it is unaffected by my patch but maybe I am missing some subtle differences.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86c3105fdb6b67fcc65e76077785b745871151b6 tdf#159515 rename impGetTransparence() to impGetAlpha() It will be available in 24.8.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 "libreoffice-24-2": https://git.libreoffice.org/core/commit/30862f999acc54e2690d28f97b95764f664c1f5a tdf#159515 rename impGetTransparence() to impGetAlpha() It will be available in 24.2.2. 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.