Description: Pattern is off (dashes instead of horizontal lines) in Presentation mode with OpenGL Steps to Reproduce: 1. Open the attached file 2. Start presentation mode (F5) Actual Results: Dashes (and the smiley eyes aren't correct either) Expected Results: No dashes Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.2.0.0.alpha0+ Build ID: 938ec2597be2e0ad3af2fb99f77de7f87285ad86 CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-05-25_23:38:38 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 142298 [details] Example file
Created attachment 142299 [details] Screenshot
i don't look dashes, but eyes have some problems (less then you have) LO 6.1 beta 1 Windows 10 regression?
(In reply to kompilainenn from comment #3) > regression? Not sure about the regression keyword, it's also broken in 6.0. Only differently (pattern outside the shape).
Created attachment 142355 [details] Viewing the example presentation in 6.1.0.0.beta1 (x64)
Created attachment 142415 [details] Bibisect log I bisected the "eyes" issue to: author Armin Le Grand <Armin.Le.Grand@cib.de (CIB)> 2018-02-23 16:57:41 +0100 committer Armin Le Grand <Armin.Le.Grand@cib.de (CIB)> 2018-03-17 23:15:49 +0100 commit d1027af3c74529827d53e8cf7b0d42a0ee47d1ba (patch) tree 488efdfb60e5e9bd01af54679872a8b91b0e14c4 parent 9886a69c472f212d88f11cfa0f3835e5dcf485b2 (diff) OperationSmiley: Added support for using same FillGeometry It is now possible to use a single FillGeometry to fill objects that are made of multiple filled objects (e.g. CustomShapes) so that they look as using a single fill. This is used for CustomShapes, but may later be 'extended' to be used for more cases. The basic functionality was already in the primitives, but had to be added to SDrObject due to these being used for CustomShapeVisualization (currently - would be better to change this to primitives, too).
Comment on attachment 142415 [details] Bibisect log >~/bibisect-win32-6.1 >$ git bisect bad >0c74725f5b066492e52cc0c81e09992127104f55 is the first bad commit >commit 0c74725f5b066492e52cc0c81e09992127104f55 >Author: Norbert Thiebaud <nthiebaud@gmail.com> >Date: Sat Mar 17 15:58:34 2018 -0700 > > source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba > > source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba > >:040000 040000 3e419b1a1dc95a7f964a338e6107aaa847ee2ccb b6632785c902150747716eed90dc423e24835bf5 M instdir > >~/bibisect-win32-6.1 >$ git bisect log ># bad: [cef8d89a77c3ca1d87bb52ae1d898271bd2689d1] source da49f4aeb8d5e9a7d2cba8855d911e7cc1d2f1e2 ># good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 >git bisect start 'origin/master' 'oldest' ># good: [f7a09816fd0c3b0433d1315de59cc22373e1627e] source 965527d76bc233b65795a5203029a65e28773e3b >git bisect good f7a09816fd0c3b0433d1315de59cc22373e1627e ># bad: [31ca4c9973bd7a4084c31506f82c223902610f96] source fe28b80dfc315dfa7f190b808f144cef6c664a29 >git bisect bad 31ca4c9973bd7a4084c31506f82c223902610f96 ># good: [a7fa1d149358544133fa94355eaee286623bda28] source 9549f0708eb0284de38290631cb46838144274ca >git bisect good a7fa1d149358544133fa94355eaee286623bda28 ># bad: [783f442a996985ad866336f6690d1c8602549e16] source 5b348b1a8ca3c5ba1049aacba1ac2e3c43ed26b7 >git bisect bad 783f442a996985ad866336f6690d1c8602549e16 ># good: [e13204a58aec76256dcf01e59ae5db860bf5fb95] source d2f95590f478a68a4de6ef05018785523e46506b >git bisect good e13204a58aec76256dcf01e59ae5db860bf5fb95 ># bad: [b243f4c069b2025be375cefc1ec7907ff8ce7876] source d414befa3f837aed3d80a77756a154e30dc6cb37 >git bisect bad b243f4c069b2025be375cefc1ec7907ff8ce7876 ># bad: [140b5391b1dede81aafcc4ed2ce05eee383ac743] source 2980e65d9728cfee73c1c49d64e19af50f756521 >git bisect bad 140b5391b1dede81aafcc4ed2ce05eee383ac743 ># bad: [31ec4f12b8387c9e41364c0efbac2b3247afa9dd] source 86c4672f4600daf19238ef25377406f445d9453a >git bisect bad 31ec4f12b8387c9e41364c0efbac2b3247afa9dd ># good: [f4d56913769eba598f148a12e9863403eab67583] source e673a47767cbd272d206ac50f2ac879d5ba71176 >git bisect good f4d56913769eba598f148a12e9863403eab67583 ># good: [a4153a2191563de2b7b00f5d456039083e460036] source a57bda77c3094558e8dae6ecec761ee4b98e5af3 >git bisect good a4153a2191563de2b7b00f5d456039083e460036 ># good: [7402c133cc8e3207614ffcc4d018c78f5961b379] source b9cf7da2907f759c98b801939e7c04cf0b80388f >git bisect good 7402c133cc8e3207614ffcc4d018c78f5961b379 ># good: [0d4ded6398a342f06fd8193f8a39123e21ae3119] source 9886a69c472f212d88f11cfa0f3835e5dcf485b2 >git bisect good 0d4ded6398a342f06fd8193f8a39123e21ae3119 ># bad: [0c74725f5b066492e52cc0c81e09992127104f55] source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba >git bisect bad 0c74725f5b066492e52cc0c81e09992127104f55 ># first bad commit: [0c74725f5b066492e52cc0c81e09992127104f55] source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba
(In reply to kompilainenn from comment #3) > i don't look dashes, but eyes have some problems (less then you have) Eye issue: bug 117910
Created attachment 142422 [details] Bibisect log I bisected the dashes to: author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2018-03-31 17:27:01 +0900 committer Tomaž Vajngerl <quikee@gmail.com> 2018-04-10 08:33:55 +0200 commit ea3d755ac949c1b6dada5c341e018f8c23f5d395 (patch) tree 086b3573d3e2f64fd918df4996d1f00ad9aa863b parent 94185507ed11bf6e2e2e9fa47c247680ae1edb36 (diff) vcl: detach usage and remove GraphicManager and GraphicCache Also remove some GraphicObjectTest because they call into GraphicManager which now doesn't exist anymore. The same commit causes a slowness for opening entering the presentation mode (6 seconds delay after the commit 2 seconds before.. Only with OpenGL enabled
Confirmed using LO 6.1 beta 1 / Windows 7.
Adding Cc: to Tomaž Vajngerl
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The problem with the eyes is fixed with my patch for bug 126184 < https://gerrit.libreoffice.org/#/c/75143/ > *** This bug has been marked as a duplicate of bug 126184 ***
Can not reproduce with Winodws 10 Home 64-bit en-US with Intel HD Graphics 620 (Driver Version 25.20.100.6519) with current master or with Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Checked the graphic and Area fill _is_ set to Horizontal line. When rendered to editmode canvas the horizontal line fill shows. And when opened to presentation mode (laptop display) same horizontal line fill. That is with OpenGL rendering mode and default (GDI) with Hardware Acceleration or CPU only rendering. In edit mode the eyes are also filled with the face's Horizontal lines, but expect that as the eyes are Z-order layer behind the face layer. The eyes have their own area fill, not sure what it is supposed to be. But in presentation mode that fill is truncated, and is filled by area fill of the face. That happens with either OpenGL rendering or Default rendering (HA, CPU). Changing the Area fill for the Smiley object from Horizontal lines to "Dashed diagonal" pattern makes the layer difference obvious, the eyes keep their area fill (though clipped in presentation) and the face's area fills in. As Xisco beleives he has fixed the issue with the eyes for bug 126184 with: https://gerrit.libreoffice.org/#/c/75143/ when that rolls to daily we can test. Otherwise it kind of suggests the issue is an OpenGL driver issue handling the lines for folks on Windows 7 (so far just Telesto and Aron).
Created attachment 152601 [details] attachment 142298 [details] open LO 6242 in Presentation mode w OpenGL
Created attachment 152602 [details] open LO 6242 in Edit mode w OpenGL
I cannot reproduce any problem with the lines with Skia (and this is now in the list of Skia bugs). Please check if you can reproduce and provide more info.
Created attachment 164999 [details] fill of smilly face eyes during presentation--Skia Vulkan Affecting Skia rendering as well as OpenGL. Likewise default GDI has issues in that the fill differs (line spacing) from edit mode. Version: 7.1.0.0.alpha0+ (x64) Build ID: a486fd929d4b3e915f928ef495b6cb2b96d74a3a CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 165000 [details] fill of smilly face eyes during presentation -- default GDI
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is the same file / screenshot as bug 117910 Looks good with GDI/Skia rendering as well, since https://git.libreoffice.org/core/+/082f0b250a04e16d608ce67e08e702874f390b15 author Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Wed Nov 30 17:12:59 2022 +0100 committer Armin Le Grand <Armin.Le.Grand@me.com> Thu Dec 01 10:41:20 2022 +0100 Handle PolyPolygonGraphicPrimitive2D with used DefinitionRange correctly