1. Open attachment #170672 [details] from bug #141213 2. In the center of the slide there is an animated GIF which is completely invisible in edit mode. 3. Enter presentation mode and you'll see the animated GIF (with 24.2 and 24.8). Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1dc92b9e9951ef118d2d823d54f9a022c2e41a27 CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US This is a regression, the GIF is shown in edit mode in Version: 7.6.7.0.0+ (X86_64) / LibreOffice Community Build ID: 88f6a250076eb2a825084c84193b84f3b94ce112 CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US (Between 7.6 and 24.2 there was a transition commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Date: Fri Apr 16 20:33:10 2021 +0200 Convert internal vcl bitmap formats transparency->alpha (II) which caused half a dozen or so regressions; maybe it fixed bug #141213 while also being responsible for this regression?)
Reproducible Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: faadf7c15593521c0ebceb043f82f916ee5ccf9d CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
bibisected 24.8 in windows 10 to 9fb3970a1a599eae2447f6746597843434ee758b (But not sure if it is releated) bump product version to 24.8.0.0.alpha0+. Date: Fri Dec 08 16:09:10 2023 +0100
Bibisected with windows 10, version 24.8 which points to cc60e2eacdf2d55e0f52754d1e0801479b199615 Author: Noel Grandin <noel.grandin@collabora.co.uk> AuthorDate: 2024-03-16 07:31:14 +0100 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164865 commit message: reduce symbol visibility in vcl
I don't think that bisect result is right. This was broken somewhere before my commit.
Hi Noel, let me check it again.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Patrick Luby ; Could you possibly take a look at this one? Thanks 42ed678aa24ff8e4283998ae38662842452e9df2 is the first bad commit commit 42ed678aa24ff8e4283998ae38662842452e9df2 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Aug 10 14:04:04 2023 +0200 source 12fd870113a663dde5ceb38c61f1986a34095d0e 155429: tdf#156630 eliminate opaque parts when drawing animated PNG images | https://gerrit.libreoffice.org/c/core/+/155429
If I apply the following debug patch, on macOS this bug no longer occurs in the document window, printing, or export to PDF. Unfortunately, this swapping of code that create alpha masks cause tdf#156630 to reoccur so there must to something different between the animated images. I will continue debugging and post again when I have some news: diff --git a/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx b/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx index d756e6e3b74f..03cecb5c6a7e 100644 --- a/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx +++ b/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx @@ -180,12 +180,12 @@ namespace drawinglayer::primitive2d BitmapEx bitmap; if( useAlphaMask ) { - const AlphaMask aMaskBitmap(maVirtualDeviceMask->GetBitmap(Point(), maVirtualDeviceMask->GetOutputSizePixel())); + const Bitmap aMaskBitmap(maVirtualDeviceMask->GetBitmap(Point(), maVirtualDeviceMask->GetOutputSizePixel())); bitmap = BitmapEx(aMainBitmap, aMaskBitmap); } else { - Bitmap aMaskBitmap(maVirtualDeviceMask->GetBitmap(Point(), maVirtualDeviceMask->GetOutputSizePixel())); + AlphaMask aMaskBitmap(maVirtualDeviceMask->GetBitmap(Point(), maVirtualDeviceMask->GetOutputSizePixel())); // tdf#156630 invert the alpha mask aMaskBitmap.Invert(); // convert from transparency to alpha bitmap = BitmapEx(aMainBitmap, aMaskBitmap);
I think I found the cause: GIF images with color palettes of 16 colors or less need additional handling. I have a fix (see following debug patch) but I need to do more testing before I submit it to make sure it doesn't cause tdf#157635 or tdf#157793 to reoccur: diff --git a/vcl/source/filter/igif/gifread.cxx b/vcl/source/filter/igif/gifread.cxx index c3151f3274d0..6c3deb4da3d0 100644 --- a/vcl/source/filter/igif/gifread.cxx +++ b/vcl/source/filter/igif/gifread.cxx @@ -683,10 +683,10 @@ void GIFReader::CreateNewBitmaps() // Due to the switch from transparency to alpha in commit // 81994cb2b8b32453a92bcb011830fcb884f22ff3, mask out black // pixels in bitmap. - if (bEnhance) - aAnimationFrame.maBitmapEx = BitmapEx( aBmp8, aBmp8 ); - else - aAnimationFrame.maBitmapEx = BitmapEx( aBmp8 ); + Bitmap aAlphaMask( aBmp8 ); + if (!bEnhance) + aAlphaMask.Invert(); + aAnimationFrame.maBitmapEx = BitmapEx( aBmp8, aAlphaMask ); } aAnimationFrame.maPositionPixel = Point( nImagePosX, nImagePosY );
(In reply to Patrick Luby (volunteer) from comment #9) > I think I found the cause: GIF images with color palettes of 16 colors or > less need additional handling. I have a fix (see following debug patch) but > I need to do more testing before I submit it to make sure it doesn't cause > tdf#157635 or tdf#157793 to reoccur: Update: I submitted the following fix but found it causes a unit test to fail. The unit test code looks fine so it is clear to me that my fix will cause some unexpected bugs: https://gerrit.libreoffice.org/c/core/+/167563 So, I think I need to rework the section of code that my fix modifies to avoid inverting the bitmap. I will post again when I have more news to report.
Created attachment 194114 [details] GIF image that make CppunitTest_sw_tiledrendering evaluates
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2a9eb581f0edfae8123018006df5cc9de1e1fd45 tdf#160690 set an opaque alpha mask for non-transparent frames 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.
I have committed a fix this bug. The fix should be in tomorrow's (15 May 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/73b552139906e10f004bd56e53684cceed071bd6 tdf#160690 set an opaque alpha mask for non-transparent frames It will be available in 24.2.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.
Happy to verify this as fixed with the last nightly snapshot: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1b45ca1aa7d7cb8e7adcc07f8c60e26a413eca8c CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US