Created attachment 189949 [details] Sample slide (PPTX) This looks like one of those transparency issues that have been introduced with 24.2 alpha: In edit mode Impress shows this slide as PowerPoint does in edit and presentation mode. In presentation mode Impress suddenly renders some of the graphics much lighter. 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: cba8c933d1ff2e31ec55544f46d6fff99e8a5ccd CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
Created attachment 189950 [details] Visual comparison PowerPoint and Impress in edit mode (left) vs Impress in presentation mode (right)
Created attachment 189951 [details] Sample slide (PPTX)
Confirmed in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2902ab24ecc5ffbf4907ea83b2028508b9de6364 CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Especially the shape named "Pentagon 91", which has multi step gradient bg is way brighter than in PP. Seems to have begun in https://git.libreoffice.org/core/+/81994cb2b8b32453a92bcb011830fcb884f22ff3 author Noel Grandin <noelgrandin@gmail.com> Fri Apr 16 20:33:10 2021 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> Tue Jul 25 08:38:12 2023 +0200 Convert internal vcl bitmap formats transparency->alpha (II) Adding CC to: Noel Grandin
I can also reproduce this on macOS with Skia/Metal, Skia/Raster, and Skia disabled. I will try to find where in the code that draws this shading when running a slideshow.
Created attachment 190414 [details] Transparency setting that triggers the bug
(In reply to Patrick Luby from comment #5) > Created attachment 190414 [details] > Transparency setting that triggers the bug So I have narrowed down which property is triggering this bug. In attachment https://bugs.documentfoundation.org/attachment.cgi?id=190414 I have marked the transparency property that triggers this bug. If you select the rectangle that is selected in that attachment and change the transparency property marked in red to "Axial" and then back to "Linear". Then, doe the same for each "chevron" shape and the slideshow will display normally. So, my current theory is that the linear transparency gradient is getting ignored until the property setting is toggled. Next I will see if I can find where this particular linear transparency gradient is drawn during a slideshow.
I did some debugging and I have narrowed down a little more where in the code the bug is occurring. The following debug patch disables the alpha masks for the problematic shapes so that I can see that the underlying unmasked image is the same and it is definitely the same in the document window, slideshow window, and export to PDF so the bug must be in the alpha mask. Next step: try to find out why the FillGradientPrimitive2D that is used for the alpha mask is different in slideshow and export to PDF. All of the parameters used to construct all of the FillGradientPrimitive2D instances are the same in the document window, slideshow window, and export to PDF so there must be some other variable to influences creation of a gradient alpha mask: diff --git a/svx/source/sdr/primitive2d/sdrdecompositiontools.cxx b/svx/source/sdr/primitive2d/sdrdecompositiontools.cxx index 50f66391d95e..7bdb4393c34f 100644 --- a/svx/source/sdr/primitive2d/sdrdecompositiontools.cxx +++ b/svx/source/sdr/primitive2d/sdrdecompositiontools.cxx @@ -443,6 +443,7 @@ sal_uInt32 SlideBackgroundFillPrimitive2D::getPrimitive2DID() const Primitive2DContainer aContent { pNewFillPrimitive }; return Primitive2DReference(new UnifiedTransparencePrimitive2D(std::move(aContent), rFill.getTransparence())); } +/* else if(!rFillGradient.isDefault()) { // create sequence with created fill primitive @@ -462,6 +463,7 @@ sal_uInt32 SlideBackgroundFillPrimitive2D::getPrimitive2DID() const return Primitive2DReference(new TransparencePrimitive2D(std::move(aContent), std::move(aAlpha))); } else +*/ { // add to decomposition return pNewFillPrimitive;
Created attachment 190820 [details] Object drawn without alpha mask in document window (no bug)
Created attachment 190821 [details] Object drawn without alpha mask in slideshow window
Working from a different angle, I was able to separately dump to disk the content without any masking and its alpha mask for one of the objects in attachement 189951. Surprisingly, when running a slideshow, the content without any masking (https://bugs.documentfoundation.org/attachment.cgi?id=190821) is only black and white but in a document window (https://bugs.documentfoundation.org/attachment.cgi?id=190820) there is no bug and there is a greenish gradient as expected. Note to myself: I enabled dumping of bitmaps to file using the following patch and setting VCL_DUMP_BMP_PATH=1: diff --git a/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx b/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx index 28d383230eef..1b79684dc6c7 100644 --- a/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx +++ b/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx @@ -457,7 +457,7 @@ void impBufferDevice::paint(double fTrans) #ifdef DBG_UTIL // VCL_DUMP_BMP_PATH should be like C:/path/ or ~/path/ - static bool bDoSaveForVisualControl(false); // loplugin:constvars:ignore + static bool bDoSaveForVisualControl(true); // loplugin:constvars:ignore static const OUString sDumpPath(OUString::createFromAscii(std::getenv("VCL_DUMP_BMP_PATH"))); if (!sDumpPath.isEmpty() && bDoSaveForVisualControl)
Created attachment 190832 [details] Very simple file that reproduces the bug for easier debugging
(In reply to Patrick Luby from comment #11) > Created attachment 190832 [details] > Very simple file that reproduces the bug for easier debugging OK. So after my surprisingly findings in comment 10, I created the simplest file that I could that reproduces this bug. What I found is that even without any effects, the function that dumps the bitmaps to files was getting called 10+ times per window and only the last time would draw as only black. I tweaked my debug patch in comment 10 and so that the other dumps before the last all have the correct gradient as their image content, but the dump alpha mask keeps changing in each call. Just to confirm my latest finding, I applied the following debug patch to disable the alpha masks and the problematic shape is rendered (albeit incorrectly) the same in the document window, slideshow window, and export as PDF. So, it looks like comment 10 was a false positive and we are back to where I was in comment 7: diff --git a/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx b/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx index 28d383230eef..2d20bf9fcae7 100644 --- a/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx +++ b/drawinglayer/source/processor2d/vclhelperbufferdevice.cxx @@ -488,7 +488,8 @@ void impBufferDevice::paint(double fTrans) #endif Bitmap aContent(mpContent->GetBitmap(aEmptyPoint, aSizePixel)); - mrOutDev.DrawBitmapEx(maDestPixel.TopLeft(), BitmapEx(aContent, aAlphaMask)); + // mrOutDev.DrawBitmapEx(maDestPixel.TopLeft(), BitmapEx(aContent, aAlphaMask)); + mrOutDev.DrawBitmapEx(maDestPixel.TopLeft(), BitmapEx(aContent)); } else if (0.0 != fTrans) {
I had a breakthrough today and I finally found a way to fix this bug: https://gerrit.libreoffice.org/c/core/+/159742 I still want to test this fix a bit more before I commit it. In the meantime, can anyone test the fix in their Windows or Linux local build?
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9a0dad2a649066a10ace53a06d563596330199a0 tdf#157558 invert and remove blended white color 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.
I did some light testing with several Impress documents that have semi-transparent images and/or gradients and I found no obvious changes as a result of my fix. So, my fix should be in tomorrow's (21 November 2023) nightly master build.
Happy to confirm my original case indeed is resolved with that last nightly build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7d357628d6e8ce3f9e3c3a567ada21f02bce8d42 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Thank you, Patrick! With that all issues caused by "Convert internal vcl bitmap formats transparency->alpha (II)" that I encountered are addressed; are there any others left?