Description: I created 3 circles, with Hatching, Bitmap and Pattern fill. Each circle has a shadow. If I enter presentation mode, the shadows have the same fill as their corresponding circles. Steps to Reproduce: 1. Open the attached document 2. Enter presentation mode (F5) Actual Results: The shadows have the same fill as their corresponding circles. Expected Results: The shadows should be gray. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: This appears to be inherited from OOo. Reproduced in: Version: 6.4.0.0.alpha0+ Build ID: e4be4c2641c0072af25cf1a2b2abc3b1cffa1078 CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Version: 5.2.7.2 (x64) Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2)
Created attachment 152168 [details] circles.odp
Isn't it a dup of tdf#125730 and so already fixed with https://cgit.freedesktop.org/libreoffice/core/commit/?id=d85499381177bbd050ed85f66f4386d5f41db237 (3 days ago)?
Nope, it isn't a dup. tdf#125730 appeared when editing the slides. This bug appears only in full screen mode. Proposed partial fix (for hatching): https://gerrit.libreoffice.org/#/c/73964/
*** Bug 119480 has been marked as a duplicate of this bug. ***
Created attachment 152332 [details] circle_bitmap.xml
Created attachment 152333 [details] circle_pattern.xml
Created attachment 152334 [details] screenshot1.png
While searching for a fix for this bug, I noticed some strange behaviors: A. XPATHFILL_SEQ_BEGIN / XPATHFILL_SEQ_END I dumped two GDIMetafiles, corresponding to the second and third circles in circles.odp. There are apparently unneeded XPATHFILL_SEQ_BEGIN / XPATHFILL_SEQ_END around the shadows. As you can see in cppcanvas/source/mtfrenderer/implrenderer.cxx, from line 1676, each time a XPATHFILL_SEQ_BEGIN is found, a bitmap is set. line 1747: aTexture.Bitmap = vcl::unotools::xBitmapFromBitmapEx( aBmpEx ); Steps to dump the GDIMetafiles: (I have a debug build on 88debc8746) 1. make debugrun 2. run --impress 3. Open the file circles.odp 4. Once the file is loaded, set a breakpoint on drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx, at line 1728: (closing brace of function VclMetafileProcessor2D::processPolyPolygonGraphicPrimitive2D) 5. Go to fullscreen mode. The breakpoint is hit 4 times: 2 for the second circle and 2 for the third circle. 6. hit 1: continue hit 2: print mpMetaFile->dumpAsXml("circle_bitmap.xml") hit 3: continue hit 4: print mpMetaFile->dumpAsXml("circle_pattern.xml") If I comment out lines 1725 and 1727 in vclmetafileprocessor2d.cxx, then this bug is fixed for the Bitmap fill, but there is a regression for the Pattern fill (see screenshot1.png). B. Pattern fill: hundreds of rectangles are drawn when only one is sufficient This is the cause of the precedent regression. You can see that if you compare the content inside <push flags="PushClipRegion"></push> in both xml. Now, my questions: - Should problem A. be fixed by including some sort of check in implrenderer.cxx before setting the texture bitmap ? Or should it be fixed by replacing/removing XPATHFILL_SEQ_BEGIN / XPATHFILL_SEQ_END in vclmetafileprocessor2d.cxx ? - The objects containig the circles seem to be created via UNO. Should problem B. be filed as a separate bug ?
Andrés: I can't help here. You should talk about it on LO dev irc or on LO dev forum.
Dear Andrés Maldonado, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Andrés Maldonado committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9c64e8a2948c379c537ee0882afa57882facb26e tdf#125901: apply color modifiers when drawing hatch It will be available in 6.5.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.
Andrés Maldonado committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/8afbdca88d55c06ced483b9b0c63fc8ab532314a tdf#125901: apply color modifiers when drawing hatch It will be available in 6.4.0.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.
The commit fixes the problem with the hatch's color, however, the other 2 cycles still have problems and they should be reported in follow-up bugs. @Andrés, would you mind doing it ? Issue verified in Version: 6.5.0.0.alpha0+ Build ID: b9e86836d79039a28661dfb6195df0a4dc1e7572 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Andrés, thanks for fixing this issue!!
(In reply to Xisco Faulí from comment #13) > The commit fixes the problem with the hatch's color, however, the other 2 > cycles still have problems and they should be reported in follow-up bugs. > @Andrés, would you mind doing it ? Reported in bug 129852