Created attachment 120424 [details] Image shows the issue The image shows the background of the slide not scaled to full screen. A white strip in the right and bottom confirm. Versão: 5.0.3.2 ID de compilação: e5f16313668ac592c1bfb310f4390624e3dbfb75 Local: pt-BR (pt_BR.UTF-8)
Created attachment 120425 [details] File with issue in
renders fine under Win8.1 x64 using LibO 5.0.3.1 and recent 5.1.0.0 daily build would you please tell your exact Linux distro and version, your graphic card and the screen resolution of your monitor(s)?
did you tested with older LibO releases to see if the bug is a regression or an old one?
Kubuntu 15.10 olivier@olivier-ntbk:~$ uname -a Linux olivier-ntbk 4.2.0-17-generic #21-Ubuntu SMP Fri Oct 23 19:56:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Laptop Dell Vostro 3560 (i7, 8GB, Intel graphics and AMD graphics) Main display is Intel. lspci -k: (..) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) Subsystem: Dell Device 056e Kernel driver in use: i915 (..) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7500M/7600M Series] (rev ff) Kernel driver in use: radeon Screen is 1920 x 1080 laptop.
Repro, but not with 3.5.0. Not related to OpenGL setting. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI) Version: 5.1.0.0.alpha1+ Build ID: b216cc1b8096eb60c27f67e8c27b7cd756c75e38 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-12_00:06:20 Locale: fi-FI (fi_FI) 3.5.0
Reproducible with Version: 4.5.0.0.alpha0+ Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb, win7
render fine in Win7x64 SP1 using LibO 5.0.3.1 I wonder why I don't reproduce it...
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
Priority: Normal - can prevent high quality/professional work; Highest - I think this qualifies, native format, regression, major feature (backgrounds in a presentation), etc... Two bibisects - at one point things works correctly -> then there was no background at all -> then it got to the current state. The bibisects: Bibisect #1: Moving from no background -> current state Bibisect #2: Moving from right -> no background +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 98011212e3ccd9334f4112d8312cfd2087624283 is the first bad commit commit 98011212e3ccd9334f4112d8312cfd2087624283 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 23:46:43 2015 +0800 source-hash-2ddfaf1f03135c10d33e0e99ebe8a56d3783d214 commit 2ddfaf1f03135c10d33e0e99ebe8a56d3783d214 Author: Armin Le Grand <alg@apache.org> AuthorDate: Wed Jul 23 16:35:32 2014 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Jul 24 13:08:15 2014 +0100 Resolves: fdo#81598 #i125300# enhanced handling of multiple ClipRegions... in MetafileProcessor (cherry picked from commit 02e2c7b225036c6478a1f7e8315a9c8361025a7f) Change-Id: Iefefc36c040507795bc2c25fe8d4a610eb12adb9 :040000 040000 2e78de6d68baaac9f88c621ef42a3b303b2b79d1 fdc88fc5ca2ab00d8027242975cdbe5444aee311 M opt # bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea git bisect good d9885f526fc7a09cc8f9f8ee643af1b966be24bb # bad: [c779cf7967f4d14c5e649a5c696b07279d550efd] source-hash-e9c5022580f14c0ca97503f8b3cc56b530fff174 git bisect bad c779cf7967f4d14c5e649a5c696b07279d550efd # good: [030e0477638f9d9110ad62f88fd4b881521e0541] source-hash-1a6e47e3fda10e6d220b67d766ec6fbdfd852b80 git bisect good 030e0477638f9d9110ad62f88fd4b881521e0541 # good: [c9e7f255b30a0410226b2074702aeba9b49dce13] source-hash-2d5a7c36ee9ae7ff39d8415f81fb911ff822548e git bisect good c9e7f255b30a0410226b2074702aeba9b49dce13 # bad: [0996e94321008e9f1857c299efad9dc3bc6e5ff2] source-hash-6c1f2ea2aa11b2c8fd42b455c7c452194ed2c1e7 git bisect bad 0996e94321008e9f1857c299efad9dc3bc6e5ff2 # good: [c69835b63d379747e58c9d6315dbf32a09e842ef] source-hash-d5fb4b731938c22fcf9c5e3280da8f722b5492e4 git bisect good c69835b63d379747e58c9d6315dbf32a09e842ef # good: [90012cb7ba832730701e29655d352a5929a14161] source-hash-81b594afa7162552fc2489ba0c7e1e8b5addb4f2 git bisect good 90012cb7ba832730701e29655d352a5929a14161 # bad: [5bd8a7898e84515432797814189a8fdec6967587] source-hash-d60cec0e60c5c0880f8098d39443c391abed80b2 git bisect bad 5bd8a7898e84515432797814189a8fdec6967587 # bad: [de0297a7c9427f6cc6eb3d81d14963e3a4b7de2f] source-hash-6794856e797ec6c758af6397f4d0df7f9150d2ef git bisect bad de0297a7c9427f6cc6eb3d81d14963e3a4b7de2f # bad: [4ca25ac7d57cb7958230981850b9fcaa477b766b] source-hash-7f9de609fb6679907e1e10563c11f475bac7b65c git bisect bad 4ca25ac7d57cb7958230981850b9fcaa477b766b # bad: [98011212e3ccd9334f4112d8312cfd2087624283] source-hash-2ddfaf1f03135c10d33e0e99ebe8a56d3783d214 git bisect bad 98011212e3ccd9334f4112d8312cfd2087624283 # good: [883604282766e705001a45bea49ecbcf8771b012] source-hash-ba4b92389bd7df92e1eddf025ad03ee6355cabfa git bisect good 883604282766e705001a45bea49ecbcf8771b012 # first bad commit: [98011212e3ccd9334f4112d8312cfd2087624283] source-hash-2ddfaf1f03135c10d33e0e99ebe8a56d3783d214 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ba6eb41acb8df58f3009920f8ab8b32a3e1b764e is the first bad commit commit ba6eb41acb8df58f3009920f8ab8b32a3e1b764e Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 01:59:31 2012 +0000 source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc commit ae4e4a11d4300f7448cb6bd170fcb034542caddc Author: Rene Engelhard <rene@debian.org> AuthorDate: Tue Nov 6 21:24:32 2012 +0100 Commit: Rene Engelhard <rene@debian.org> CommitDate: Tue Nov 6 21:24:32 2012 +0100 typo... Change-Id: I2c7968194afbcf74967cd16c639dce7de858a513 :100644 100644 c09b92a8ddf24b8738a7cd3a695ae1e4482d354c 6b13afd13f023cedac65a896318de4aa55dead27 M autogen.log :100644 100644 bcee1e11bd693642ca5a6330175b58082e5dcdd0 54d2377f5b3afd6ed668b3e24cb877c289119ec5 M ccache.log :100644 100644 75677cef16786d2cc95c0d8f301482278ca055c3 d18a6ebcd3b8537c3dd3dbc16e862fb6370ecb8a M commitmsg :100644 100644 83b4ecc0ecb3e031c804d49f45f854e95d5cc961 d482c00e5fff6081c6b87b637fd9ffaf3e1e2c6c M dev-install.log :100644 100644 91437b9974ffada7e049273419bb8c66c91c0539 abf45ab9609c77a5ab952aa310eafe8c2ffaf85c M make.log :040000 040000 45c0bab8b669778ab523c8f65a25e8c9afde604a f4bfa15b2f72d3df5675b07bcf32254a819b9d19 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # skip: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect skip e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # skip: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f git bisect skip 9daa289e178460daaafa4b3911031df5b8736218 # bad: [387dd1052972d27a3065a249b357e50e0a29829b] source-hash-35836f350861b33a0c28307a413eff76d0433d1e git bisect bad 387dd1052972d27a3065a249b357e50e0a29829b # bad: [251dbe932a666e83c91816fcf755a4c3be51e078] source-hash-fff4d120866a0be3cd8185f2c67bb9f59b1a6a3f git bisect bad 251dbe932a666e83c91816fcf755a4c3be51e078 # good: [daa21bbd8c7b50e2ca1c2cbed0e39f0e7b5a1cb2] source-hash-6b11a18071254a443c8fe7e7b0b1c95b0f9fd35e git bisect good daa21bbd8c7b50e2ca1c2cbed0e39f0e7b5a1cb2 # good: [56de98328b5e6e28aae1f5a8574c4d6500abdf82] source-hash-5f91f8a368343d8921a01edb7359cd300892f09d git bisect good 56de98328b5e6e28aae1f5a8574c4d6500abdf82 # bad: [e5973caebe5b9637f93a4da008d76b33b9d5ff6a] source-hash-683758efb22d08a4cf211a6d985148f513da2a90 git bisect bad e5973caebe5b9637f93a4da008d76b33b9d5ff6a # good: [91fed7198400158ba17622fa48f1c85063ba839f] source-hash-7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d git bisect good 91fed7198400158ba17622fa48f1c85063ba839f # good: [1e4f8bf8304c7ecaaf68f2d16f09ef2f97d10af7] source-hash-fe347327a44f2d8ed201f9fbc2ae4858f34962d8 git bisect good 1e4f8bf8304c7ecaaf68f2d16f09ef2f97d10af7 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # good: [fae90325861bbddd2af90937d29d91637c96661a] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588 git bisect good fae90325861bbddd2af90937d29d91637c96661a # bad: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc git bisect bad ba6eb41acb8df58f3009920f8ab8b32a3e1b764e # first bad commit: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
Seems to have to do with the MasterPageBackgroundImage being a SVG. Using the same as PNG works well. SVGs may be embedded to ClipRegions when content overlaps SVG range definition (see svgio, SvgSvgNode::decomposeSvgNode), but that is used for some time.
Checked, not the reason. When pres starts, three MaskPrimitive2D are processed in VclMetafileProcessor2D. When suppressing the 1st one, all is looking good. Need to dig deeper. Since internals there are like they are for some time I'm wondering if or to what this is a regression. Same happens e.g. with Version: 4.4.7.1, Version: 4.3.7.2, Version: 4.2.8.2. It does not happen in Version: 4.1.6.2, Version 4.0.6.2, and Version 3.6.7.2. Thus, must have been added between 4.1.6.2 and 4.2.8.2.
There are two Regions created using B2DPolyPolygons which lead to problems, one created at svgio import, one when PolyPolygonGraphicPrimitive2D gets decomposed. Both are used for long time and for display, so there must be an error somewhere on the transfer of these regions to the slideshow. Tried to break at WriteRegion/ReadRegion which I thought might be used when the Metafile is handed over to the slideshow, but it is not...
Checked all primitive creators, pref sizes and embeddings, looks good. Metafile is tunneled to presentation, thus the B2DPolyPolygon will survive. Need to check directly what slideshow does with MetaActionType::CLIPREGION...
Leaving all clippings out in cppcanvas ImplRenderer::createActions does not help and shows that all SVG data reation is indeed correct - what is lost is when cppcanvas tries to render that SVG itself as graphic. Can be proved by not using the same image as background, but as regular graphic -> effect in the slideshow is the same, internal parts of the SVG graphic are painted wrong (the background, while other parts are correct). Thus: The error is that the canvas renderer is not capable to render this SVG correctly. I am not a canvas-renderer specialist.
The SVG gets embedded with it's primitives just in a transformation expressing it's geometric positioning (as it should be). Thus the wrong-painted part of it should reside in the same metafile (the primitives get processed using the MetafileRenderer, slideshow does not use primitives (yet)). Trying to extract/strip the example
Poblem is cppcanvas\source\mtfrenderer\transparencygroupaction.cxx line 371. Some hard to understand corrections on canvas transformation state. If not executing this, all works correctly. We have to ask Thorsten, it's old stuff mixed with some new one (last is commit af1514abf26b2070bd342ce449f209a42f3989e5). Thorsten...?
Did some tests. There are two possibilities which make TransparencyGroupAction::renderSubset work: (1) Leave out aScaleCorrection (2) Add 'aLocalState.Clip.clear();' after setRenderStateTransform
Checked deeper, (1) only seems to work since it is a gradient. Using a test file which clearly shows the borders (attaching stripped, modified one) makes this a no-op. What happens is that the scale needs to be taken out, but the local clip is then wrong (if used). Thus, (2) splits in (a) clearing clip or (b) adapting clip to the scale-adaption, too. That would involve convert clip from XPolyPolygon2D to B2DPolyPolygon, transform, convert back and set. It depends if this is ever used - (a) is fast, (b) is correct. Did I mention that all this would be obsolete when presentation would use primitives...?
Created attachment 123012 [details] Stripped, adapted SVG
Implemented clip adaption, works well. Preparing solution...
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c85800345239754d5c4ec71c2aad526d0439eea tdf#95709 adapt clip polygon for transparence groups It will be available in 5.2.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.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0244e043c1aca4a9e63313998254202e40f113b&h=libreoffice-5-1 tdf#95709 adapt clip polygon for transparence groups It will be available in 5.1.2. 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.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd37ff21753afe37dc7185fddf34adf33dc9291f&h=libreoffice-5-0 tdf#95709 adapt clip polygon for transparence groups It will be available in 5.0.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.