Description: If you open an APNG file like the attached one, you'll notice the opaque parts of the image are fully transparent. Bibisected to: https://gerrit.libreoffice.org/c/core/+/114168 (81994cb2b8b32453a92bcb011830fcb884f22ff3) Steps to Reproduce: 1. Open attached APNG file in Draw 2. Rendering is now wrong Actual Results: Otherwise opaque pixels are transparent Expected Results: See before commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Reproducible: Always User Profile Reset: No Additional Info: -
Created attachment 188792 [details] broken apng
Noel, any ideas?
On pc Debian x86-64 with master sources updated today, I could reproduce this. I noticed this log: warn:vcl:22848:22848:vcl/source/bitmap/BitmapEx.cxx:135: BitmapEx: forced mask to monochrome
Created attachment 188802 [details] Screen snapshot of drawing artifacts near trunk and tail
(In reply to Patrick Luby from comment #4) > Created attachment 188802 [details] > Screen snapshot of drawing artifacts near trunk and tail I rebuilt master with the latest code this morning on macOS and what I see is normal animation of the .png image. The only bug that I still see is that there are drawing artifacts left over near the elephant's trunk and tail (see https://bug-attachments.documentfoundation.org/attachment.cgi?id=188802). The artifacts get cleared about every second or so maybe clipping and clearing is the issue. Interestingly, in LibreOffice RC 7.6.0.2, there is no animation at all when I open the .apng image in Draw. So maybe the "animate in place" is a new feature on master?
(In reply to Patrick Luby from comment #5) > The artifacts get cleared about every second or so maybe clipping and > clearing is the issue. Interestingly, in LibreOffice RC 7.6.0.2, there is no > animation at all when I open the .apng image in Draw. So maybe the "animate > in place" is a new feature on master? Note to self: add a call to MiscSettings::GetUseReducedAnimation() to turn off animation if it returns true. If MiscSettings::GetUseReducedAnimation() returns true, it should override the internal LibreOffice "animate text" preference like we did for the Calc copy border in https://bugs.documentfoundation.org/show_bug.cgi?id=155414. I will see if I can track down which LibreOffice code does the animated drawing.
Created attachment 188804 [details] Screencast My observations 1. The white area around the elephant should be transparent, or at least it was before 2. The APNG is animating, however the tail shows artifacts 3. The performance is abysmal with Skia/Raster on macOS. Makes LibreOffice pretty unresponsive Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b3053b63c65372627c5fb4df6b4ddcd5e12e16f7 CPU threads: 8; OS: Mac OS X 13.4.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #7) > 1. The white area around the elephant should be transparent, or at least it > was before > 2. The APNG is animating, however the tail shows artifacts I now see what you describe. I'll look at the filled white background first as I am guessing that fixing that might also eliminate the trunk and tail drawing artifacts.
Created attachment 188808 [details] Screenshot Windows It looks even worse on Windows (build 9 days ago) Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to Telesto from comment #9) > Created attachment 188808 [details] > Screenshot Windows > > It looks even worse on Windows (build 9 days ago) > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win > Locale: nl-NL (nl_NL); UI: en-US > Calc: CL threaded FYI that's the bug I'm talking about that I get on linux as well (In reply to Patrick Luby from comment #5) > (In reply to Patrick Luby from comment #4) > > Created attachment 188802 [details] > > Screen snapshot of drawing artifacts near trunk and tail > > I rebuilt master with the latest code this morning on macOS and what I see > is normal animation of the .png image. The only bug that I still see is that > there are drawing artifacts left over near the elephant's trunk and tail > (see > https://bug-attachments.documentfoundation.org/attachment.cgi?id=188802). > > The artifacts get cleared about every second or so maybe clipping and > clearing is the issue. Interestingly, in LibreOffice RC 7.6.0.2, there is no > animation at all when I open the .apng image in Draw. So maybe the "animate > in place" is a new feature on master? APNG support didn't exist in 7.6, I added it recently.
(In reply to Paris Oplopoios from comment #10) > APNG support didn't exist in 7.6, I added it recently. That is good to know. I found the following patch of yours which should save me a ton of time trying to find which code controls the drawing: https://gerrit.libreoffice.org/c/core/+/153556 My first guess is that the transparency->alpha patch in master will now require an AlphaMask.Invert() to be added or removed from some in the drawing calls like was needed to fix the following slideshow animation bug: https://bugs.documentfoundation.org/show_bug.cgi?id=156540
(In reply to Telesto from comment #9) > Created attachment 188808 [details] > Screenshot Windows > > It looks even worse on Windows (build 9 days ago) > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win > Locale: nl-NL (nl_NL); UI: en-US > Calc: CL threaded Note: I somewhat overlooked that Skia being disabled here. So this only happens on Windows in GDI mode. It looks OK with Skia/Raster (unable to test Vulkan on my Windows machine)
Created attachment 188810 [details] Screenshot FWIW: There also rendering glitches for the APNG in impress presentation mode (with Skia enabled). But maybe a different bug belonging to a new bug report
Created attachment 188811 [details] Example of broken export to PDF rendering
(In reply to Patrick Luby from comment #14) > Created attachment 188811 [details] > Example of broken export to PDF rendering I am also seeing drawing problems when using Skia/Raster on macOS. Interestingly, the following change fixes all rendering problems in a document window and export to PDF (but not slideshow) for Skia/Metal and Skia/disabled. I don't want to commit the following diff but it really amplifies the Skia/Raster problems so next I will see if I can figure out why Skia/Raster is different than Skia/Metal: diff --git a/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx b/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx index f3c4cf69911c..5a765c1fdd16 100644 --- a/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx +++ b/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx @@ -104,6 +104,8 @@ namespace drawinglayer::primitive2d maVirtualDeviceMask->EnableMapMode(false); maVirtualDevice->SetOutputSizePixel(aTarget); maVirtualDeviceMask->SetOutputSizePixel(aTarget); + maVirtualDevice->SetBackground(COL_BLACK); + maVirtualDeviceMask->SetBackground(COL_ALPHA_TRANSPARENT); } maVirtualDevice->Erase();
Created attachment 188832 [details] Animation with Skia/Raster on macOS. Note the gray outline in the bottom half which is 2x scaled.
Update: I think that I have fixed some of the bugs seen so far: https://gerrit.libreoffice.org/c/core/+/155429 This patch fixes the following: - Eliminates the opaque background when opening https://bugs.documentfoundation.org/attachment.cgi?id=188792 in Draw or in Impress - I may have fixed the Windows GDI rendering problems described in https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c12 Still todo before I commit the patch: - Fix opaqueness surrounding image when running a slideshow - Add native accessibility check described in https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c6 - Fix the macOS-only Skia window scaling problems described in https://bugs.documentfoundation.org/show_bug.cgi?id=156629#c10 - Fix random drawing of black alpha mask when exporting to PDF with Skia/Metal when image is opened in Draw and the document background is set to an opaque color. This may be related to the macOS-only Skia window scaling problems.
New update: the 2x scaling with Skia/Raster no longer occurs after rebasing my local build and doing a clean rebuild so here is the most current todo list: - Find out why an assert is now being hit with Skia/Metal and Skia/Raster (new) - Fix drawing of black alpha mask when exporting the image to PDF with > Skia/Metal or Skia/Raster. This occurs on the first time that you export the image to PDF after launching LibreOffice. Subsequent exports are fine. (updated) - Fix opaqueness surrounding image when running a slideshow (no change) - Add native accessibility check described in https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c6 (no change)
Update: the 2x scaling problem with Skia/Raster on macOS reappeared after I found that I had SAL_FORCE_HIDPI_SCALING=1 in my environment. But fortunately, I found the fix for that and the "firt export to PDF after launch" bugs. So now the only thing left to fix is the following: - Fix opaqueness surrounding image when running a slideshow Slideshow is apparently done in a completely separate code path so I still need to track that down. What seems strange to me is that I needed to force the alpha mask to be rendered to a bitmap in the following: https://gerrit.libreoffice.org/c/core/+/155429/4/drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx Does this work on Windows or Linux? Also, I wonder if the above fix is why Windows and Linux were not using the alpha mask at all to paint if Skia is disabled. Does setting useAlphaMask to true in all cases like is done on macOS still not work? I ask this because when useAlphaMask is false, a much grainier and darker version of the image is drawn (i.e. the same rendering as when running a slideshow).
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/12fd870113a663dde5ceb38c61f1986a34095d0e tdf#156630 eliminate opaque parts when drawing animated PNG images 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 188906 [details] Before patch, all platforms used lower resolution drawing path
Created attachment 188907 [details] After patch, all platforms (except Windows and Linux with Skia disabled) use high resolution drawing path
Update: I think that I have fixed all of the animation problems reported in this bug and my fixes should be in tomorrow's (10 August 2023) nightly master build. I did make one small change. I noticed that without my fixes, all platforms would use a low resolution drawing path when running animated images in a slideshow like in https://bugs.documentfoundation.org/attachment.cgi?id=188906. In contrast, in an Impress document window, this low resolution drawing path is only used when Skia is disabled on Windows and Linux so I added the same high resolution drawing path logic in Impress document windows to slideshows so that it lools like https://bugs.documentfoundation.org/attachment.cgi?id=188907.
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.
Created attachment 188982 [details] screenshot Margins not very sharp. See screenshot. Tested with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
In fact, the margins should NOT be black, but colored, or not at all.
(In reply to BogdanB from comment #25) > Created attachment 188982 [details] The - even more - obvious problem is the shadow below the belly. It should be light gray, not black
(In reply to Telesto from comment #27) > (In reply to BogdanB from comment #25) > > Created attachment 188982 [details] > > The - even more - obvious problem is the shadow below the belly. It should > be light gray, not black Same when using GDI on Windows. Fine with Skia (Raster); there are other glitches Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 518fa99dd7693d64a53e404a065090aedc0002b1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to BogdanB from comment #25) > Created attachment 188982 [details] > screenshot > > Margins not very sharp. See screenshot. > > Tested with > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb > CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 > Locale: ro-RO (ro_RO.UTF-8); UI: en-US > Calc: threaded I noted this in my comment https://bugs.documentfoundation.org/show_bug.cgi?id=156630#c23 that this Window and Linux code was explicitly implemented by someone in the past when running on Windows or Linux and Skia is disabled. I am a macOS developer and I do not have access to Windows or Linux so I am extremely reluctant to change any specific Windows or Linux code. All I know is that the original developers explicitly implemented different logic for macOS than for Windows and Linux. Should any Windows or Linux developers want to try removing this special "Skia disabled" code path, the code is here: drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx:176 slideshow/source/engine/shapes/gdimtftools.cxx:350
Few other observations on Windows 1. Insert -> Image -> inserts. A non-animating image is inserted on Windows for Draw/Impress/Calc (except presentation mode of Impress) Animated images are allowed (Tools -> Options -> Accessibility -> Allow Animated Images) 2. Insert -> Image -> In Writer has still glitches. Tail showing artifacts similar to what previously existed in Draw. Also black belly on a certain frame (using Skia Raster). Writer uses different rendering, so not really a surprise. 3. The Elephant is walking in slowmotion with Skia Raster in Impress presentation mode. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 518fa99dd7693d64a53e404a065090aedc0002b1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to Telesto from comment #30) > Few other observations on Windows > 1. Insert -> Image -> inserts. A non-animating image is inserted on Windows > for Draw/Impress/Calc (except presentation mode of Impress) Animated images > are allowed (Tools -> Options -> Accessibility -> Allow Animated Images) > Do you have the native Windows settings for reduced animations set? If that is set, it overrides LibreOffice's internal settings like was done for the Calc animated copy border: https://bugs.documentfoundation.org/show_bug.cgi?id=155414 The native Windows that LibreOffice now looks at are in the commit comment in the following commit: https://git.libreoffice.org/core/+/609ed2944b030a692c942428afa8bf7c3ac93672%5E%21 Note: when the native "reduce animation" setting is enabled on Windows or macOS, it will stop animation of the .png in a document window, but it won't stop animation in a slideshow.
Just for the record, on pc Debian x86-64 with master sources updated today + some changing to have useAlphaMask = true in drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx and in slideshow/source/engine/shapes/gdimtftools.cxx at code locations indicated by Patrick, the animation is better on Draw and Impress (a bit slow but no sharp edges and a light gray shadow below instead of black). In Impress, when enabling slideshow, the fact it's slower is more noticeable since the end of the tail of the elephant shows some artifacts. (tested with gtk3 and gen renderings). Anyway, even if it's still slow (above all in slideshow mode) with useAlphaMask = true, I think it's better since with useAlphaMask = false it's even slower + we got some artefacts
(In reply to Patrick Luby from comment #31) > Do you have the native Windows settings for reduced animations set? If that > is set, it overrides LibreOffice's internal settings like was done for the > Calc animated copy border: > > https://bugs.documentfoundation.org/show_bug.cgi?id=155414 > > The native Windows that LibreOffice now looks at are in the commit comment > in the following commit: > > https://git.libreoffice.org/core/+/ > 609ed2944b030a692c942428afa8bf7c3ac93672%5E%21 Well, that's explains it. I'm still using Windows 8.1 (end of support). bEnableAnimation is set to FALSE by default if I read correctly. Windows 8.1 does probably not support "SPI_GETCLIENTAREAANIMATION" So it's stuck with disabled...
(In reply to Telesto from comment #33) > ... > Well, that's explains it. I'm still using Windows 8.1 (end of support). > bEnableAnimation is set to FALSE by default if I read correctly. Windows 8.1 > does probably not support "SPI_GETCLIENTAREAANIMATION" So it's stuck with > disabled... Taking a look at SPI_GETCLIENTAREAANIMATION, it seems defined in winuser.h but this one isn't included in these files. According to https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfoa, this parameter is not supported for Windows Server 2003 and Windows XP/2000 but hope it should be ok with Windows 8.1. Anyway, I searched about all "SPI_" in the code and here's a list: SPI_GETWHEELSCROLLLINES defined in vcl/inc/win/wincomp.hxx 104 SPI_GETFLATMENU defined in vcl/inc/win/wincomp.hxx 0x1022 SPI_GETFONTSMOOTHING not defined SPI_GETFONTSMOOTHINGTYPE not defined SPI_GETFONTSMOOTHINGORIENTATION not defined SPI_GETSCREENREADER not defined FE_FONTSMOOTHINGCLEARTYPE not defined SPI_GETWHEELSCROLLCHARS defined in vcl/win/window/salframe.cxx 0x006C SPI_GETWORKAREA not defined SPI_GETWHEELSCROLLLINES not defined SPI_GETHIGHCONTRAST not defined SPI_GETCARETWIDTH not defined SPI_GETNONCLIENTMETRICS not defined SPI_GETICONTITLELOGFONT not defined SPI_GETDRAGFULLWINDOWS not defined SPI_GETCLIENTAREAANIMATION not defined winuser.h only included in vcl/win/dtrans/source.cxx Mike: since you've already worked a bit on LO with Windows internal, thought you might be interested in this list. I mean, I just wonder if the manual define shouldn't be removed and winuser.h included in some files, what do you think ?
(In reply to Julien Nabet from comment #34) > Mike: since you've already worked a bit on LO with Windows internal, thought > you might be interested in this list. > I mean, I just wonder if the manual define shouldn't be removed and > winuser.h included in some files, what do you think ? You are right, these are not needed anymore - https://gerrit.libreoffice.org/c/core/+/155751 Note that it's not needed to include winuser.h directly - it's included indirectly by windows.h.
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.