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?)
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
Created attachment 126772 [details] test document open in Writer portions of .svm corrupted on opening and while scrolling
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 60b74fe1775e647545d2da1fcc58a4c63ec18aa5 # good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source 49c2b9808df8a6b197dec666dfc0cda6321a4306 git bisect start 'origin/master' 'oldest' # bad: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source c0da1080b61a1d51654fc34fdaeba373226065ff git bisect bad 38f37b8ec1a2d199bb957cfd2581df7d1b273b74 # good: [6998931a34ad75eb555f882fbed223e585548721] source 1fbd073828ef52f5206aed4643226bae9fb85f4f git bisect good 6998931a34ad75eb555f882fbed223e585548721 # bad: [b283fbadb387862ea0f09058430317906e1a78b5] source 1fc4cb57755cdfb9ab65c112435997874fb057cd git bisect bad b283fbadb387862ea0f09058430317906e1a78b5 # good: [46053f8f06492a2c806ebd473883548d4a1115d8] source 3de2c3952b9757c40615194811142fd19a9b72eb git bisect good 46053f8f06492a2c806ebd473883548d4a1115d8 # bad: [67a60fe21b0a52702588b1337face4a45ea247bf] source 3187193a6142b4b1c974ae1e1de572fa74a3c8ee git bisect bad 67a60fe21b0a52702588b1337face4a45ea247bf # good: [0891028d34a92b73ff4cf8989493b185119c25b9] source 626702aa39798715fd252ae8f484233cae8a829f git bisect good 0891028d34a92b73ff4cf8989493b185119c25b9 # good: [eb8c97174c2a19746b4baaff4b518e04dc965359] source 13ebef097dbbf1e8663bcb3649daba4ee8295a40 git bisect good eb8c97174c2a19746b4baaff4b518e04dc965359 # good: [ba3a00102b4517035b4daaeae62ae44c521af8f7] source 2c5f8927349cf0e643e0bfebf4d9aa5b726b0f89 git bisect good ba3a00102b4517035b4daaeae62ae44c521af8f7 # bad: [72d08f16e124e0726e74e2cff95252ff66374a16] source e973b342826e54f147251b132c3325d30749e312 git bisect bad 72d08f16e124e0726e74e2cff95252ff66374a16 # bad: [52786e0487c39a7b89020b341ad9782b2b3a78c6] source 1db7af8bc9febdf72138fac533ec81d6983da729 git bisect bad 52786e0487c39a7b89020b341ad9782b2b3a78c6 # bad: [dd38a8d8a5eeeb2de3f06735b35ae25d4d645640] source 6f12c93703b676b1b3839caaf2c21788e5d68477 git bisect bad dd38a8d8a5eeeb2de3f06735b35ae25d4d645640 # good: [81f4994d7f77b371a74bda23f50cf4137bd40bdd] source 1d0f08cdf1b9396e97e068f97fd78f31b5906748 git bisect good 81f4994d7f77b371a74bda23f50cf4137bd40bdd # first bad commit: [dd38a8d8a5eeeb2de3f06735b35ae25d4d645640] source 6f12c93703b676b1b3839caaf2c21788e5d68477
Adding Cc: to Armin Le Grand
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.
Opened in a 5.1.0.3 I still had and indeed works there, in Writer and Draw/Impress. Thus this needs deeper investigation.
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.
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...?
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 ;-)
Just made 100% sure: Case 'EMR_ALPHABLEND' which was added by the bibisected commit is not used when that graphic is loaded
@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?
Seems fine on Linux / master. What happens if the given commit is reverted ;-)
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
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.
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.
@Caolan: Yepp, that's it! Good find :-) One remark: 'ROP_OVERPAINT -> RasterOp::OverPaint' someone changed the enum on current master...
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.
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.
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.