Bug 125901 - Impress: Shadow has the same fill as the shape (in full screen)
Summary: Impress: Shadow has the same fill as the shape (in full screen)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Andrés Maldonado
URL:
Whiteboard: target:6.5.0 target:6.4.0.2
Keywords:
: 119480 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-06-13 13:36 UTC by Andrés Maldonado
Modified: 2020-01-07 10:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
circles.odp (50.19 KB, application/vnd.oasis.opendocument.presentation)
2019-06-13 13:38 UTC, Andrés Maldonado
Details
circle_bitmap.xml (3.20 KB, text/xml)
2019-06-21 09:29 UTC, Andrés Maldonado
Details
circle_pattern.xml (105.82 KB, text/xml)
2019-06-21 09:30 UTC, Andrés Maldonado
Details
screenshot1.png (257.54 KB, image/png)
2019-06-21 09:30 UTC, Andrés Maldonado
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrés Maldonado 2019-06-13 13:36:44 UTC
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)
Comment 1 Andrés Maldonado 2019-06-13 13:38:17 UTC
Created attachment 152168 [details]
circles.odp
Comment 2 Julien Nabet 2019-06-13 13:56:50 UTC
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)?
Comment 3 Andrés Maldonado 2019-06-13 14:04:03 UTC
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/
Comment 4 Xisco Faulí 2019-06-13 15:28:54 UTC
*** Bug 119480 has been marked as a duplicate of this bug. ***
Comment 5 Andrés Maldonado 2019-06-21 09:29:23 UTC
Created attachment 152332 [details]
circle_bitmap.xml
Comment 6 Andrés Maldonado 2019-06-21 09:30:03 UTC
Created attachment 152333 [details]
circle_pattern.xml
Comment 7 Andrés Maldonado 2019-06-21 09:30:50 UTC
Created attachment 152334 [details]
screenshot1.png
Comment 8 Andrés Maldonado 2019-06-21 09:31:24 UTC
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 ?
Comment 9 Julien Nabet 2019-07-20 17:13:42 UTC
Andrés: I can't help here. You should talk about it on LO dev irc or on LO dev forum.
Comment 10 Xisco Faulí 2019-11-21 12:35:54 UTC
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.
Comment 11 Commit Notification 2019-12-27 12:28:50 UTC
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.
Comment 12 Commit Notification 2019-12-27 23:39:09 UTC
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.
Comment 13 Xisco Faulí 2019-12-29 14:04:26 UTC
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!!
Comment 14 Xisco Faulí 2020-01-07 10:27:31 UTC
(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