Description: I have a svg image with very slim rectangles (staff lines, see attached svg file). The screen preview is fine when displayed at zoom level 140% and above. At zoom level 120% and below, the staff lines are displayed much thicker. Steps to Reproduce: 1. Create new Writer/Draw/Impress document 2. Insert image file "OOoLilyPond.svg" (see attached) 3. Increase / decrease zoom level Actual Results: In Writer/Draw/Impress, when zoom level is set to 120% or less, screen preview is broken: Staff lines are displayed much too thick. PDF export and slide show are not affected. Expected Results: Image preview should be correct at any zoom level. Reproducible: Always User Profile Reset: No Additional Info: I'm not quite sure if a version earlier than 6.2.2.2 has been affected. 6.1.5.2 release was still without this issue.
Created attachment 150887 [details] Sample SVG file
I confirm it with Version: 6.3.0.0.alpha0+ (x64) Build ID: 421e6fc3cd2e6fe37afbef341e2d0ad7b8edde37 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-07_01:12:58 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded and with Version: 6.2.3.2 (x64) Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded but not with Version: 5.4.7.2 (x64) Build-ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL
This seems to have begun at the below commit. Adding Cc: to Armin Le Grand; Could you possibly take a look at this one? Thanks 7127ec0b63ddd55b4f0f6c5b268fcc7fe1fdcdfb is the first bad commit commit 7127ec0b63ddd55b4f0f6c5b268fcc7fe1fdcdfb Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Aug 30 12:27:56 2018 -0700 source b9fa01a8d1137a95af9865a3e47995734c40da6e author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-08-24 13:01:08 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-08-30 19:48:46 +0200 commit b9fa01a8d1137a95af9865a3e47995734c40da6e (patch) tree 6d1e0a3e44b1a96fe5302d779c00fbee55cf8d24 parent f4a9ce33415a85d0b86ced3a0bf780f4ec61e25f (diff) Support buffering SystemDependent GraphicData
Sorry for bumping... ...has anybody already found something that can help here? Or is this bug of minor importance and won't be fixed in the near future?
*** Bug 127026 has been marked as a duplicate of this bug. ***
Also reproducible in Version: 6.4.0.0.alpha1+ Build ID: ee909ca2c02f949605f68720c3f1eef658502749 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
grepping on my list - probably has to do with LOs speciality to always paint lines with width 0 (zero) as one pixel, independent of zoom...may have to be avoided for SVG subcontent (what may be pretty hard to do)
Can reproduce (Linux/Win). Note & Workarond: Does not happen when right-context-menu at inserted object and 'Break' -> local geometry decomposition. What is bad since it means that the wrong transform of LineWidth is somewhere inside the SVG stack...
Indeed has to do with that: In VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect there is a test (if(basegfx::fTools::more(fLineWidth, 0.0))) if the pixel target is small enough to fallback to LineWidth==0 what is LO's specialty for Hairlines (defines as one-pixel wide lines, independent from Zoom, originating from ancient times when there was no AntiAliasing). Commenting out // draw simple hairline fLineWidth = 0.0; makes it work. This means that on the rendering side (e.g. WinSalGraphicsImpl::drawPolyLine) a back-transformed LineWidth corresponding to one pixel and the given transformation has to be used. Currently a 1.0 is used coming from in-between. Usually this works (e.g. when breaking it up) what means that in SVG context the transformation is set while in Broken state it is empty. Will check that...
Adaption is in OutputDevice::DrawPolyLineDirect, thus on the system-independent side. This can be adapted there. It would be better to do that on the system-dependent side and use the hairline-definition through the whole stack.
Not that easy - in the system-dependent renderers (grep for bool .*::drawPolyLine) that do not pass the transformation to the trarget graphic system there are corrections of the form // need to check/handle LineWidth when ObjectToDevice transformation is used const basegfx::B2DVector aDeviceLineWidth(rObjectToDevice * rLineWidth); const bool bCorrectLineWidth(aDeviceLineWidth.getX() < 1.0 && rLineWidth.getX() >= 1.0); const basegfx::B2DVector aLineWidth(bCorrectLineWidth ? rLineWidth : aDeviceLineWidth); thus this error *must* be system-dependent. @KlausBlum, @Dieter, @raal: On which system did you do that...? Please note here, this may get important.
Created attachment 158410 [details] Linux x64 vs Windows x86 Hi Armin, i can reproduce it both on Linux and Windows
Hi Armin, I had it running on Windows 10 x64.
(In reply to Xisco Faulí from comment #12) > Created attachment 158410 [details] > Linux x64 vs Windows x86 > > Hi Armin, > i can reproduce it both on Linux and Windows @Xisco: Do you know which graphic subsystem is active then...?
...or to be more precise: Error will be dependent on graphic SubSystem, not just OS. Please have a look at Tools/options/view...
Indeed, the issue is gone is anti-aliasing is not used
Yes, NonAA is a factor, but...we have seven Graphic SubSystems: - gdiplus - skia - opengl - X11 - Qt5 - Quartz - Cairo On Win, it's gdiplus/skia or opengl, on linux it's skia/opengl/X11 or Cairo, ...
Decided to do a bigger but necessary cleanup of hairline stuff through all the layers. This might be not without the danger of causing regressions, but I see no alternative. Since we now use PolyPolygon area and line methods that hand over the transformation so that the graphic subsystem can use it directly, it is necessary to be able to handle hairline cases there. Thus, it is necessary to get zero line width through down there and handle it as needed. For subsystems that transform and use just discrete coordinates (pixels) this will be to convert a linewidth of zero (hairline) to 1, for those who use the transformation in the subsystem it means to back-calculate a view-independent, logic line width that will represent a single pixel. Doing deeper tests on deeper changes. Main work here is to find all ocurrences that by purpose use a 1.0 or B2DVector(1.0, 1.0) for line width - hairline - and replace with 0 resp. 0.0 as needed.
There are two caveats: (1) Places where 1/1.0 is used as line width may cause very thin lines - will need to find these in the future (2) Had to adapt some of the seven graphic subsystems 'blind', but that will be checked by gerrit
1st changes are on https://gerrit.libreoffice.org/c/core/+/90057, but may definitely contain errors yet - using gerrit for test builds on other systems...
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd117712bd5692f7bf3870ba91572a0bab54ab86 tdf#124848 partial refactor hairline logic It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Have now committed that change to master. I see no more possibilities to test deeper myself - already played around a lot, loaded many bugdocs of the past. This is one of the cases where you need to get it live to get feedback. I will be ready for smaller drawbacks...
No hiccups yet - a good sign.
Tested on Windows 10. Looks good so far. Thanks for fixing this! Is there a chance that this will be backported to a release prior to 7.0.0?
(In reply to Klaus Blum from comment #24) > Tested on Windows 10. Looks good so far. > Thanks for fixing this! > > Is there a chance that this will be backported to a release prior to 7.0.0? @Xisco - as long as no errors surface, why not...
(In reply to Armin Le Grand from comment #25) > (In reply to Klaus Blum from comment #24) > > Tested on Windows 10. Looks good so far. > > Thanks for fixing this! > > > > Is there a chance that this will be backported to a release prior to 7.0.0? > > @Xisco - as long as no errors surface, why not... ok, I tried to cherry-picked it locally but there are many conflicts. @Armin, feel free to backport yourself if you want to, I'm afraid I could break something if I do it so I prefer not to do it myself
BTW, issue verified in Version: 7.0.0.0.alpha0+ Build ID: 9d7fdcd6b5c7b5a9fe781bb99b135fba7d04ddec CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded @Armin, thanks for fixing it!
As this is complicated stuff (and no proof not breaking anything else) I opt to not port back as long as not urgently requested.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eab7585891edb53bf240f8b9173f1870be271568 fix tdf#124848 test on Mac It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.