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)
Dashes (and the smiley eyes aren't correct either)
User Profile Reset: No
OpenGL enabled: Yes
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]
Created attachment 142299 [details]
i don't look dashes, but eyes have some problems (less then you have)
LO 6.1 beta 1 Windows 10
(In reply to kompilainenn from comment #3)
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 188.8.131.52.beta1 (x64)
Created attachment 142415 [details]
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)
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]
>$ git bisect bad
>0c74725f5b066492e52cc0c81e09992127104f55 is the first bad commit
>Author: Norbert Thiebaud <email@example.com>
>Date: Sat Mar 17 15:58:34 2018 -0700
> source sha:d1027af3c74529827d53e8cf7b0d42a0ee47d1ba
> source sha:d1027af3c74529827d53e8cf7b0d42a0ee47d1ba
>:040000 040000 3e419b1a1dc95a7f964a338e6107aaa847ee2ccb b6632785c902150747716eed90dc423e24835bf5 M instdir
>$ git bisect log
># bad: [cef8d89a77c3ca1d87bb52ae1d898271bd2689d1] source sha:da49f4aeb8d5e9a7d2cba8855d911e7cc1d2f1e2
># good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source sha:6eeac3539ea4cac32d126c5e24141f262eb5a4d9
>git bisect start 'origin/master' 'oldest'
># good: [f7a09816fd0c3b0433d1315de59cc22373e1627e] source sha:965527d76bc233b65795a5203029a65e28773e3b
>git bisect good f7a09816fd0c3b0433d1315de59cc22373e1627e
># bad: [31ca4c9973bd7a4084c31506f82c223902610f96] source sha:fe28b80dfc315dfa7f190b808f144cef6c664a29
>git bisect bad 31ca4c9973bd7a4084c31506f82c223902610f96
># good: [a7fa1d149358544133fa94355eaee286623bda28] source sha:9549f0708eb0284de38290631cb46838144274ca
>git bisect good a7fa1d149358544133fa94355eaee286623bda28
># bad: [783f442a996985ad866336f6690d1c8602549e16] source sha:5b348b1a8ca3c5ba1049aacba1ac2e3c43ed26b7
>git bisect bad 783f442a996985ad866336f6690d1c8602549e16
># good: [e13204a58aec76256dcf01e59ae5db860bf5fb95] source sha:d2f95590f478a68a4de6ef05018785523e46506b
>git bisect good e13204a58aec76256dcf01e59ae5db860bf5fb95
># bad: [b243f4c069b2025be375cefc1ec7907ff8ce7876] source sha:d414befa3f837aed3d80a77756a154e30dc6cb37
>git bisect bad b243f4c069b2025be375cefc1ec7907ff8ce7876
># bad: [140b5391b1dede81aafcc4ed2ce05eee383ac743] source sha:2980e65d9728cfee73c1c49d64e19af50f756521
>git bisect bad 140b5391b1dede81aafcc4ed2ce05eee383ac743
># bad: [31ec4f12b8387c9e41364c0efbac2b3247afa9dd] source sha:86c4672f4600daf19238ef25377406f445d9453a
>git bisect bad 31ec4f12b8387c9e41364c0efbac2b3247afa9dd
># good: [f4d56913769eba598f148a12e9863403eab67583] source sha:e673a47767cbd272d206ac50f2ac879d5ba71176
>git bisect good f4d56913769eba598f148a12e9863403eab67583
># good: [a4153a2191563de2b7b00f5d456039083e460036] source sha:a57bda77c3094558e8dae6ecec761ee4b98e5af3
>git bisect good a4153a2191563de2b7b00f5d456039083e460036
># good: [7402c133cc8e3207614ffcc4d018c78f5961b379] source sha:b9cf7da2907f759c98b801939e7c04cf0b80388f
>git bisect good 7402c133cc8e3207614ffcc4d018c78f5961b379
># good: [0d4ded6398a342f06fd8193f8a39123e21ae3119] source sha:9886a69c472f212d88f11cfa0f3835e5dcf485b2
>git bisect good 0d4ded6398a342f06fd8193f8a39123e21ae3119
># bad: [0c74725f5b066492e52cc0c81e09992127104f55] source sha:d1027af3c74529827d53e8cf7b0d42a0ee47d1ba
>git bisect bad 0c74725f5b066492e52cc0c81e09992127104f55
># first bad commit: [0c74725f5b066492e52cc0c81e09992127104f55] source sha: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]
I bisected the dashes to:
author Tomaž Vajngerl <firstname.lastname@example.org> 2018-03-31 17:27:01 +0900
committer Tomaž Vajngerl <email@example.com> 2018-04-10 08:33:55 +0200
commit ea3d755ac949c1b6dada5c341e018f8c23f5d395 (patch)
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
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!
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 184.108.40.20619) with current master or with
Version: 220.127.116.11 (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
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: 18.104.22.168.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
Created attachment 165000 [details]
fill of smilly face eyes during presentation -- default GDI