Download it now!
Bug 124848 - Parts of svg image not displayed correctly at smaller zoom levels (anti-aliasing)
Summary: Parts of svg image not displayed correctly at smaller zoom levels (anti-alias...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:7.0.0
Keywords: bibisected, bisected, filter:svg, regression
: 127026 (view as bug list)
Depends on:
Blocks: SVG-Import Zoom-Issues
  Show dependency treegraph
 
Reported: 2019-04-19 22:13 UTC by Klaus Blum
Modified: 2020-05-27 16:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample SVG file (11.26 KB, image/svg+xml)
2019-04-19 22:14 UTC, Klaus Blum
Details
Linux x64 vs Windows x86 (119.47 KB, image/png)
2020-03-05 13:30 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Blum 2019-04-19 22:13:22 UTC
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.
Comment 1 Klaus Blum 2019-04-19 22:14:31 UTC
Created attachment 150887 [details]
Sample SVG file
Comment 2 Dieter 2019-04-22 05:03:18 UTC
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
Comment 3 raal 2019-04-29 11:49:04 UTC
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 sha: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
Comment 4 Klaus Blum 2019-08-17 09:42:00 UTC
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?
Comment 5 Xisco Faulí 2019-09-18 11:03:53 UTC
*** Bug 127026 has been marked as a duplicate of this bug. ***
Comment 6 Xisco Faulí 2019-11-05 09:10:12 UTC
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
Comment 7 Armin Le Grand 2020-01-23 08:41:49 UTC
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)
Comment 8 Armin Le Grand 2020-03-05 08:41:11 UTC
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...
Comment 9 Armin Le Grand 2020-03-05 12:58:50 UTC
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...
Comment 10 Armin Le Grand 2020-03-05 13:03:50 UTC
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.
Comment 11 Armin Le Grand 2020-03-05 13:25:56 UTC
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.
Comment 12 Xisco Faulí 2020-03-05 13:30:38 UTC
Created attachment 158410 [details]
Linux x64 vs Windows x86

Hi Armin,
i can reproduce it both on Linux and Windows
Comment 13 Klaus Blum 2020-03-05 13:36:30 UTC
Hi Armin, 

I had it running on Windows 10 x64.
Comment 14 Armin Le Grand 2020-03-05 14:01:44 UTC
(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...?
Comment 15 Armin Le Grand 2020-03-05 14:03:32 UTC
...or to be more precise: Error will be dependent on graphic SubSystem, not just OS. Please have a look at Tools/options/view...
Comment 16 Xisco Faulí 2020-03-05 14:41:31 UTC
Indeed, the issue is gone is anti-aliasing is not used
Comment 17 Armin Le Grand 2020-03-05 15:56:22 UTC
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, ...
Comment 18 Armin Le Grand 2020-03-05 18:17:24 UTC
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.
Comment 19 Armin Le Grand 2020-03-05 18:22:31 UTC
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
Comment 20 Armin Le Grand 2020-03-05 18:30:50 UTC
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...
Comment 21 Commit Notification 2020-03-06 09:12:21 UTC
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.
Comment 22 Armin Le Grand 2020-03-06 09:13:43 UTC
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...
Comment 23 Armin Le Grand 2020-03-10 09:01:09 UTC
No hiccups yet - a good sign.
Comment 24 Klaus Blum 2020-03-10 21:23:17 UTC
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?
Comment 25 Armin Le Grand 2020-03-15 18:12:54 UTC
(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...
Comment 26 Xisco Faulí 2020-03-19 16:45:01 UTC
(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
Comment 27 Xisco Faulí 2020-03-19 16:47:06 UTC
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!
Comment 28 Armin Le Grand 2020-03-30 15:08:47 UTC
As this is complicated stuff (and no proof not breaking anything else) I opt to not port back as long as not urgently requested.
Comment 29 Commit Notification 2020-05-06 17:36:05 UTC
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.