Bug 101433 - Embedded StarView metafile is corrupted when inserted into document canvas
Summary: Embedded StarView metafile is corrupted when inserted into document canvas
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0 target:5.2.3 target:5.1.6
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-08-10 12:11 UTC by christian.rufener
Modified: 2016-10-04 13:53 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
File containing Metafile Image (28.41 KB, application/vnd.oasis.opendocument.text)
2016-08-10 12:11 UTC, christian.rufener
Details
test document open in Writer portions of .svm corrupted on opening and while scrolling (32.09 KB, image/png)
2016-08-12 13:52 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description christian.rufener 2016-08-10 12:11:27 UTC
Created attachment 126727 [details]
File containing Metafile Image

Having a document from internal source containing an image (probably via windows metafile paste). The document looks ok in 5.1.0.3 but terrible in any version after. 

Steps to reproduce:
Open attached document in 5.1.0.3, scroll up and down the pages -> Image looks ok
Open it in 5.2.0.4, scroll up and down the pages -> Looks bad (artifacts, redraw issues?)
Comment 1 V Stuart Foote 2016-08-12 13:50:48 UTC
Reproduced when OpenGL rendering has been disabled. The canvas area to the left of the vertical axis is rendered with a part of the StarView meta graphic.

clip attached

Extracting the .svm from the archive and opening into Draw, the same corruption of that area of the graphic occurs.

Looks to be a filtering issue in handling the .svm

Interestingly, OpenGL rendering when enabled does not have a problem with it.


On Windows 10 Pre 64-bit en-US with
Version: 5.2.0.4 (x64)
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
Locale: en-US (en_US)

and on a recent build of master

Version: 5.3.0.0.alpha0+
Build ID: 07966a9999b0b3f27e1adeea1f4c97b3ba2944fa
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-08-05_23:36:50
Locale: en-US (en_US); Calc: CL
Comment 2 V Stuart Foote 2016-08-12 13:52:12 UTC
Created attachment 126772 [details]
test document open in Writer portions of .svm corrupted on opening and while scrolling
Comment 3 raal 2016-09-28 11:47:55 UTC
This seems to have begun at the below commit.
Adding Cc: to Armin.Le.Grand@cib.de; Could you possibly take a look at this one? Thanks

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2016-01-22 10:39:41 (GMT)
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2016-01-29 12:02:11 (GMT)
commit	6f12c93703b676b1b3839caaf2c21788e5d68477 (patch)
tree	b62b26ed86f6e656ca66d85e828abd2475f03bc0
parent	1d0f08cdf1b9396e97e068f97fd78f31b5906748 (diff)
tdf#91017 Enhance WMF import of EMR_ALPHABLEND action	
	
	 git bisect log
# bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source sha:60b74fe1775e647545d2da1fcc58a4c63ec18aa5
# good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source sha:49c2b9808df8a6b197dec666dfc0cda6321a4306
git bisect start 'origin/master' 'oldest'
# bad: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source sha:c0da1080b61a1d51654fc34fdaeba373226065ff
git bisect bad 38f37b8ec1a2d199bb957cfd2581df7d1b273b74
# good: [6998931a34ad75eb555f882fbed223e585548721] source sha:1fbd073828ef52f5206aed4643226bae9fb85f4f
git bisect good 6998931a34ad75eb555f882fbed223e585548721
# bad: [b283fbadb387862ea0f09058430317906e1a78b5] source sha:1fc4cb57755cdfb9ab65c112435997874fb057cd
git bisect bad b283fbadb387862ea0f09058430317906e1a78b5
# good: [46053f8f06492a2c806ebd473883548d4a1115d8] source sha:3de2c3952b9757c40615194811142fd19a9b72eb
git bisect good 46053f8f06492a2c806ebd473883548d4a1115d8
# bad: [67a60fe21b0a52702588b1337face4a45ea247bf] source sha:3187193a6142b4b1c974ae1e1de572fa74a3c8ee
git bisect bad 67a60fe21b0a52702588b1337face4a45ea247bf
# good: [0891028d34a92b73ff4cf8989493b185119c25b9] source sha:626702aa39798715fd252ae8f484233cae8a829f
git bisect good 0891028d34a92b73ff4cf8989493b185119c25b9
# good: [eb8c97174c2a19746b4baaff4b518e04dc965359] source sha:13ebef097dbbf1e8663bcb3649daba4ee8295a40
git bisect good eb8c97174c2a19746b4baaff4b518e04dc965359
# good: [ba3a00102b4517035b4daaeae62ae44c521af8f7] source sha:2c5f8927349cf0e643e0bfebf4d9aa5b726b0f89
git bisect good ba3a00102b4517035b4daaeae62ae44c521af8f7
# bad: [72d08f16e124e0726e74e2cff95252ff66374a16] source sha:e973b342826e54f147251b132c3325d30749e312
git bisect bad 72d08f16e124e0726e74e2cff95252ff66374a16
# bad: [52786e0487c39a7b89020b341ad9782b2b3a78c6] source sha:1db7af8bc9febdf72138fac533ec81d6983da729
git bisect bad 52786e0487c39a7b89020b341ad9782b2b3a78c6
# bad: [dd38a8d8a5eeeb2de3f06735b35ae25d4d645640] source sha:6f12c93703b676b1b3839caaf2c21788e5d68477
git bisect bad dd38a8d8a5eeeb2de3f06735b35ae25d4d645640
# good: [81f4994d7f77b371a74bda23f50cf4137bd40bdd] source sha:1d0f08cdf1b9396e97e068f97fd78f31b5906748
git bisect good 81f4994d7f77b371a74bda23f50cf4137bd40bdd
# first bad commit: [dd38a8d8a5eeeb2de3f06735b35ae25d4d645640] source sha:6f12c93703b676b1b3839caaf2c21788e5d68477
Comment 4 Xisco Faulí 2016-09-28 21:12:57 UTC
Adding Cc: to Armin Le Grand
Comment 5 Armin Le Grand 2016-09-29 09:13:36 UTC
Tested by copying the graphic to draw. Moving it there or zooming in/out repaint various errors, strange. Breaking it up shows the correct content (context menu/break). Back to Writer, the same strange errors occur.
Thus, a workaround is copy/paste to draw, break, group and copy/paste back.
The Metafile from Win is an unstable beast (see Bug 47243). The bibisect shows a commit that added a formally uninterpreted action - I doubt that this leaded to this errors.
Comment 6 Armin Le Grand 2016-09-29 09:16:40 UTC
Opened in a 5.1.0.3 I still had and indeed works there, in Writer and Draw/Impress. Thus this needs deeper investigation.
Comment 7 Armin Le Grand 2016-09-29 10:15:56 UTC
Checked the original embedded graphic, it's a '20000A9400014AC80000A8C30FAB1B8660CE966A.svm', so a StarViewMetafile. This definitively excludes the bibisected change since WMF import is not used. Using that graphic directly shows the same strange behaviour.
Comment 8 Armin Le Grand 2016-09-29 12:08:59 UTC
Checked the rendering pipeline, all looks good. Errors come from VirtualDevices not being handled/cleared correctly (used in vclhelperbufferdevice.cxx).
@Caolan, @Michael: What has changed on VirtualDevices between 5.1.0.3 and 5.2.0.4 so that these are not cleared correctly...?
Comment 9 Michael Meeks 2016-09-29 12:21:30 UTC
Good question - glad that OpenGL does it right. Ultimately, the clearing behaviour of virtual-devices and windows is something we hoped to optimize with the hyper-accelerated glClear - but that turns out to be rather hard due to the code structure, and allocation calling conventions - whereby we allocate 1x1 pixel VirtualDevices and then re-allocate them subsequently, then draw a rectangle on them to clear etc. etc.

So de-bonging the OutputDevice/VirtualDevice initialization and clearing behaviour to be remotely efficient would be something wonderful to do ;-)
Comment 10 Armin Le Grand 2016-09-29 12:34:37 UTC
Just made 100% sure: Case 'EMR_ALPHABLEND' which was added by the bibisected commit is not used when that graphic is loaded
Comment 11 Armin Le Grand 2016-09-29 12:41:53 UTC
@Michael: You are right, when forcing to OpenGL, the initialization is right - this shows even more that the error is not in the rendering pipeline on system-independent part, but on VCL-handling of VirtualDevice ;\ sigh... Any hnt what might have changed there?
Comment 12 Michael Meeks 2016-09-29 12:59:29 UTC
Seems fine on Linux / master. What happens if the given commit is reverted ;-)
Comment 13 Caolán McNamara 2016-09-29 13:14:39 UTC
I feel the problem is in the reuse of cached virtual devices which ended up with a non-default raster mode, so that the 

 // copy RasterOp (e.g. may be ROP_XOR on destination)
 mpContent->SetRasterOp(mrOutDev.GetRasterOp());

from the above commit particularly exposes the problem that the mrOutDev has a possibly arbitrary starting RasterMode
Comment 14 Commit Notification 2016-09-29 13:21:17 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=17f912c5bb63426f0758dccbc3357a73f56f3137

Resolves: tdf#101433 reset RasterOpMode on cached virtual device before reuse

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Caolán McNamara 2016-09-29 13:24:04 UTC
That seems to work for me anyway, I see this with gtk2 backend under Linux, so a double check of the above commit under windows is appreciated.
Comment 16 Armin Le Grand 2016-09-29 13:54:10 UTC
@Caolan: Yepp, that's it! Good find :-)
One remark: 'ROP_OVERPAINT -> RasterOp::OverPaint' someone changed the enum on current master...
Comment 17 Commit Notification 2016-09-29 14:17:38 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4acb1cc5da1708b4bfe55723313b09cc4d8157d&h=libreoffice-5-2

Resolves: tdf#101433 reset RasterOpMode on cached virtual device before reuse

It will be available in 5.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 V Stuart Foote 2016-09-30 03:34:37 UTC
On Windows 10 Pro 64-bit, ver 1607 en-US with
Version: 5.3.0.0.alpha0+
Build ID: 89a3f825559753d6600807342ca96c169cd58c87
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-29_23:19:33
Locale: en-US (en_US); Calc: group

Confirmed fixed now on Windows build of master with default rendering.
Comment 19 Commit Notification 2016-10-04 13:53:50 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0537b554fd4ac56c1ac1c81e268ef1713c992cbd&h=libreoffice-5-1

Resolves: tdf#101433 reset RasterOpMode on cached virtual device before reuse

It will be available in 5.1.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.