Description: Fade in effect shows white artifacts/wrong color of shape in presentation mode (Skia) Steps to Reproduce: 1. Open the attached file 2. Press F5 3. Mouse click to start the effect Actual Results: See screenshot Expected Results: Proper color and background during animation Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 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
Created attachment 188660 [details] Sample
Created attachment 188662 [details] Screenshot
I can reproduce this bug with both Skia/Metal and Skia/Raster. Interestingly, with Skia disabled, the right colors are used by instead of fading in, it fades out.
(In reply to Patrick Luby from comment #3) > I can reproduce this bug with both Skia/Metal and Skia/Raster. > Interestingly, with Skia disabled, the right colors are used by instead of > fading in, it fades out. For comparison, here is the data for the latest Libreoffice 7.6 beta build: I cannot reproduce this bug regardless of Skia setting. Conclusion: this bug is probably a side-effect of the following patch: https://gerrit.libreoffice.org/c/core/+/114168 So, any fix for this bug should only be needed in the master branch.
Unassigning myself. I couldn't find the drawing paths that these occur in, but I haven't had much time.
So I have narrowed this down a little bit. In slideshow/source/engine/shapes/viewshape.cxx, ViewShape::render() and ViewShape::renderSprite() send a GDIMetaFile to the cppcanvas code. Next steps are to see if either of the following tricks work in this case: 1. Set the AlphaMask of the sprite's underlying VirtualDevice to COL_ALPHA_TRANSPARENT 2. Add a AlphaMask.Invert() in one or more of the MetaActions in the GDIMetaFile
Update: I finally tracked down where the VirtualDevice is created in the canvas module and approach 1 has no effect. I haven't been able to implement approach 2 yet as I have yet to find where the BitmapEx (and the alpha mask that I need to invert) is drawn. What I see down in the vcl/skia code is that slideshow clears its sprite with white and then draws the shape with its bluish fill. Somewhere there is an alpha mask being filled backwards (white is opaque and black is transparent now) so my theory is that the white clearing creates an inverted alpha mask. I'll keep trying to find where an bitmap with an alpha mask is passed to the vcl/skia code during a slideshow. I would think that all of the fade in drawing would be drawn to a temporary VirtualDevice and then that is drawn with an alpha mask. I haven't been able to grab any stack traces in vcl/skia in the masked bitmaps drawing methods so either no BitmapEx is being drawn or I am looking in the wrong place.
Created attachment 188777 [details] Stack trace of the transparent bitmap drawing the fade in with Skia disabled
(In reply to Patrick Luby from comment #8) > Created attachment 188777 [details] > Stack trace of the transparent bitmap drawing the fade in with Skia disabled So I switched to Skia disabled since it actually draws a bitmap with an alpha mask. The fade in renders as a fade out, but at least I was able to get a stack trace of what is supposed to be called when Skia is enabled. First I will try to figure out where an AlphaMask.Invert() needs to be added or removed when Skia is disabled. Then I'll see if I can find what call in https://bugs.documentfoundation.org/attachment.cgi?id=188777 is unexpectedly returning Skia is enabled.
I think I have fixed this without (hopefully) breaking any other transparent drawing in the following patch: https://gerrit.libreoffice.org/c/core/+/155358 I think that it probably needs to be tested on Windows and Linux, especially with Skia disabled, before I commit it.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/52637f46cc79eb7f65a97524e92a0b2f45d3d598 tdf#156540 invert alpha when drawing sprites 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.
The fix should be in tomorrow's (06 August 2023) nightly master build.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b3053b63c65372627c5fb4df6b4ddcd5e12e16f7 Revert "tdf#156540 invert alpha when drawing sprites" 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.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ad1f69d28d31725a22e7e1cbb4d950aa9ad3bea7 tdf#156540 invert alpha mask when drawing sprites 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.
Thorsten import(In reply to Commit Notification from comment #14) > Thorsten Behrens committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > ad1f69d28d31725a22e7e1cbb4d950aa9ad3bea7 This is a more complete fix than my earlier commit. The above commit should be in tomorrow's (07 August 2023) nightly master build.