Bug 130478 - Dashed line drawing is not as fast as it could be
Summary: Dashed line drawing is not as fast as it could be
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords: perf
: 127134 (view as bug list)
Depends on:
Blocks: Performance
  Show dependency treegraph
 
Reported: 2020-02-06 08:48 UTC by Armin Le Grand
Modified: 2023-04-14 09:34 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
clip of the area with what should be dashed lines (143.74 KB, image/jpeg)
2020-03-07 08:30 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Armin Le Grand 2020-02-06 08:48:42 UTC
On all systems with all existing adaptions to target grapic systems dashed line drawing is not as fast as possible. This is despite buffering system-dependent graphic data formats. This task is about analyzing this and taking steps speeding this up.
Comment 1 Armin Le Grand 2020-02-06 08:49:06 UTC
Grepping...
Comment 2 Armin Le Grand 2020-02-06 08:55:52 UTC
Analysis reveals the following problems:
(1) System-dependent buffering does not trigger due to not being used with graphic data. The involved B2D(Poly)Polygons are subdivided internally using basegfx::utils::applyLineDashing in a pre-stage to low-level rendering, thus the orig polys are not available at low-level for buffering at all
(2) Neither dash info nor the orig polys are available in low-level sys-dep methods, so there are no alternatives to either buffer nor direct-dash-paint if available on taget system
(3) basegfx::utils::applyLineDashing while being very precise has a tendency to get slow on big data (thousands of points) simply due to expensive mem handling stuff. Doing this at every (re)paint is expensive
Comment 3 Armin Le Grand 2020-02-06 09:05:48 UTC
To solve (1) and (2), the graphics stack command chain for PolygonStrokePrimitive2D handling has to be adapted to hand over dash info and the original geometry to lower parts. This will allow
- fallback to existing, but locally in sysdep implementation as a safe, 1st step
- using sysdep buffering there at the original polygon as a 2nd step
- using sysdep direct dashed line drawing as a 3rd step

There are a lot of caveats/dangers:
- seven graphic stacks need adaption
  - gdiplus
  - skia
  - opengl
  - X11
  - Qt5
  - Quartz
  - Cairo
- buffering needs adaption low-level
- need to find and adapt all pre-stages that already use basegfx::utils::applyLineDashing and change/adapt
- take care for cases that we know, but no graphic system (e.g. linejoin none)
- support our 'special' hairline LineWidth0 -> 1 pixel (resolution-dependent)
- support fat line drawing, quite some special stuff on some systems
- be VERY careful with transparency: drawing filled polygons of created fat line geometry will NOT be correct when overlapping and not painted in a single PolyPolygon

There are more caveats, which I hopefully have in my mind, creado is that all this will need good testing.
Comment 4 Armin Le Grand 2020-02-06 09:27:49 UTC
1st steps taken:

PolygonStrokePrimitive2D: Do no longer use basegfx::utils::simplifyCurveSegments in constructors, this was done due to not being able to guarantee that this was done later

VclPixelProcessor2D::tryDrawPolygonStrokePrimitive2DDirect: prepare radical changes, do no longer dismantle dashed lines yourself

OutputDevice::DrawPolyLineDirect: Adapt to hand through dash data

ALL drawPolyLine impls/defs/usages: Adapt to hand through dash data

ALL seven SvpSalGraphics::drawPolyLine: Adapt to *use* dash data locally now

SalGraphics::DrawPolyLine: Adapt to hand through dash data besides adding mirroring to transformation

One important goal is to keep dashed draw data transformation independent to make buffering as useful as ever possible where adapted
Comment 5 Armin Le Grand 2020-02-06 09:32:11 UTC
Cairo:
SvpSalGraphics::drawPolyLine: hand through to...
SvpSalGraphics::drawPolyLine:
- adapt SystemDependentData_CairoPath to take dash info if available for buffering
- added decide if existing buffering changed (dash style check needed)
- path creation to locally use basegfx::utils::applyLineDashing is dash is used
- still need to deal with basegfx::B2DLineJoin::NONE
- needs testing
- no direct dash rendering yet, but implementation possible locally now
Comment 6 Armin Le Grand 2020-02-06 09:35:19 UTC
OpenGL:
OpenGLSalGraphicsImpl::drawPolyLine:
- local fallback to basegfx::utils::applyLineDashing added
- looping now to add result to mpRenderList->addDrawPolyLine
- not sure if PostBatchDraw can be moved outside that loop, added note there
- no buffering yet at OPenGL, is possible (was even before without dashed info, would be useful...?)
- needs testing
Comment 7 Armin Le Grand 2020-02-06 09:37:05 UTC
Qt5:
Qt5Graphics::drawPolyLine:
- local fallback to basegfx::utils::applyLineDashing added
- looping to add result usinmg AddPolygonToPath
- no buffering yet at Qt5, is/was possible (useful...?)
- needs testing
Comment 8 Armin Le Grand 2020-02-06 09:38:15 UTC
Quartz:
AquaSalGraphics::drawPolyLine:
- local fallback to basegfx::utils::applyLineDashing added
- looping to add result using AddPolygonToPath
- no buffering yet at Quartz, is/was possible (useful...?)
- needs testing
Comment 9 Armin Le Grand 2020-02-06 09:39:45 UTC
Skia:
SkiaSalGraphicsImpl::drawPolyLine:
- local fallback to basegfx::utils::applyLineDashing added
- looping to add result using addPolygonToPath
- no buffering yet at Skia (?) is/was possible (useful...?)
- needs testing
Comment 10 Armin Le Grand 2020-02-06 09:42:37 UTC
GDIPlus:
WinSalGraphicsImpl::drawPolyLine:
- adapt SystemDependentData_GraphicsPath to take dash info if available for buffering
- added decide if existing buffering changed (dash style check needed)
- path creation to locally use basegfx::utils::applyLineDashing if dash is used
- adding in loop using impAddB2DPolygonToGDIPlusGraphicsPathReal
- needs testing
- no direct dash rendering yet, but implementation possible locally now
Comment 11 Armin Le Grand 2020-02-06 09:45:52 UTC
X11:
X11SalGraphicsImpl::drawPolyLine:
- adapt SystemDependentData_Triangulation to take dash info if available for buffering
- added decide if existing buffering changed (dash style check needed)
- corrected wrong removal of basegfx::utils::createAreaGeometry (see 51b5b93092d6231615de470c62494c24e54828a1)
- path creation to locally use basegfx::utils::applyLineDashing if dash is used
- adding in loop using basegfx::utils::createAreaGeometry
- X11 is special in the sense that it creates triangle polygon data that will be filled, not just split-up line data
- needs testing
Comment 12 Armin Le Grand 2020-02-06 09:50:33 UTC
From seven targets we have:
- Three using buffering (Cairo, X11, GDIPlus)
- Four adapted to direct decompose of dash data using basegfx::utils::applyLineDashing (OpenGL, Qt5, Quartz, Skia)

There is potential for adding buffering to those four.
There is potential for direct dashed rendering in some.
This should/can be combined with buffering of system-dependent, transformation-independent geometry data ideally

This now will need quite some debugging/stabilization/testing, on it...
Comment 13 Armin Le Grand 2020-02-06 10:03:30 UTC
info: basegfx::utils::applyLineDashing is very precise and handles beziers well - keeping snippets beziers with high quality

Builds: Doing local builds, preparing 1st commit to gerrit. Marked lots of stuff with tag 'MM01' - that is for working purposes only and will be removed later/before master
Builds show:
Win builds and thus build-tests: GDIPlus/Skia/OpenGL
Linux builds and thus build-tests: Cairo/Skia/OpenGL/X11

No build test for: Qt5 and Quartz, thus early adding to gerrit is needed.
Comment 14 Armin Le Grand 2020-02-06 14:06:47 UTC
Could get a Qt5 test build running using '--enable-qt5' but missing includes due to QT5_USING_X11 being set but
    #include <QtX11Extras/QX11Info>
missing. Continue trying...

Windows: Debugging, correcting some stuff in path creation.
Comment 15 Armin Le Grand 2020-02-06 14:41:33 UTC
Checked GDIPlus and OpenGL on win. Checked Skia on win, too.
Comment 16 Armin Le Grand 2020-02-06 14:56:49 UTC
Added changes for GDIPlus.
Checking airo on Win, need to fix some stuff...
Comment 17 Armin Le Grand 2020-02-06 15:36:09 UTC
Stumbled over CornerStyle/CapStyle stuff, have to think about that. Also not fully working in current version. Problematic is CornerStyle none, realized in most cases by splitting polypolygons to single lines, but that makes CapStyle trigger if set.
CornerStyle none is anyways a LO-speciality (this style does not exist anywhere else), so have to think about what to do here.
Comment 18 Armin Le Grand 2020-02-06 16:14:16 UTC
To get line transparency working it s not possible to paint in multiple commands, thus not possible to have different LineCaps (theoretically possibe for start and end of primitive to use only LineCap for start/end, but not all GraphSystems may support that). Only other solution would be to create areafill geometry self and paint with mask/transparency idiom. 2nd arg for single command and thus single LineCap is speed/buffering and other GraphSystems. Thus this should be okay.
Consequence: If CornerStyle==none, CapStyle!=flat will create changed corners.
Comment 19 Armin Le Grand 2020-02-06 17:49:43 UTC
Back to testing/checking: Cairo on Linux is OK then.

After quite some fight: Could check/test X11 on Linux
- need to use --with-x on autogen.sh
- set {"name":"SAL_USE_VCLPLUGIN","value":"gen"}
- set {"name":"SAL_DISABLE_USE_CAIRO_FOR_FATLINES","value":"true"}
Compiles and works well - the geometry creation is the only one that currently draw the mix described above correctly.

Need to check behaviour of all versions again with findings above, still ready for 1st commit I guess.
Comment 20 Armin Le Grand 2020-02-06 17:56:47 UTC
Comitted 1st working version to gerrit, see https://gerrit.libreoffice.org/c/core/+/88130. This is work in progress (!)
Comment 21 Armin Le Grand 2020-02-07 09:17:58 UTC
Open for check are: Qt5 and Quartz, rest I could check either on Linux or Win. Qt5 will be worth a try, will do so. Quartz needs a Mac, will be the one needing compile time check in gerrit. Luckily, both are not too complex cases ('standard' fallback for using basegfx::utils::applyLineDashing and no buffering), so not too risky.
Conitinuously adding changes due to gerrit tests builds, too...
Comment 22 Armin Le Grand 2020-02-07 13:29:12 UTC
Added

            if (basegfx::B2DLineJoin::NONE == rSource.getLineAttribute().getLineJoin()
                && css::drawing::LineCap_BUTT != rSource.getLineAttribute().getLineCap())
            {
                // better use decompose to get that combination done for now, see discussion
                // at https://bugs.documentfoundation.org/show_bug.cgi?id=130478#c17 and ff
                return false;
            }

to drawinglayer\source\processor2d\vclpixelprocessor2d.cxx to use decomposed geometry for the discussed case for EditViews. Keeping fallbacks in ::drawPolyLine implementations for now, but these may be cleaned up later with falling back to basegfx::B2DLineJoin::Miter for basegfx::B2DLineJoin::NONE (as can be seen in SvpSalGraphics::drawPolyLine in vcl\headless\svpgdi.cxx already.
Comment 23 V Stuart Foote 2020-02-07 17:16:43 UTC
@Armin, great work as always!

Should you need a test doc 'in the wild'--the EMF+ attachment 156837 [details] has at least four dashed line arcs, and was choking on load (stack trace looks recursive).

Chris S was working on the EMF/EMF+ handling, and for bug 129675 seems we are sidestepping these dashed lines--but they are still there for some practical tests.
Comment 24 Commit Notification 2020-02-07 17:50:14 UTC
Armin Le Grand (Collabora) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5f61c9fe99ac93087b898adddbb4d4733f1fcd07

tdf#130478 Enhance Dashed line drawing on all systems

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 25 Armin Le Grand 2020-02-08 10:57:52 UTC
Will now add the direct-use-sysdep-dashing for Cairo...
Comment 26 Armin Le Grand 2020-02-08 11:01:35 UTC
@Stuart: Thanks, maybe I'll be able to do more here again :) Not done with this one yet, though. Will have a look at the testdoc, though, thanks for that! Not sure if loading may profit, but we'll see...
Comment 27 Armin Le Grand 2020-02-08 11:26:49 UTC
Added to gerrit, see https://gerrit.libreoffice.org/c/core/+/88262
Checked, and seems to work well. Compare with our own geometry creation by using convert/toContour in draw with some fancy lines, interestingly our stack with primitives seems to be pretty numerically identical from the result with what Cairo does - a good sign.
Defaulting this to 'on', as seen in the comment there is a bool to switch it off in case of problems. This change will now not only increase repaint (scroll/zoom due to being transformation indepent), but also 1st paint and (maybe) initial loading times.
At least for Cairo for now. Of course this should be...
- Add buffering where it is not yet done: Missing is Skia, OpenGL, Qt5, Quartz
- Add direct dashing, candidates are: All except Cairo
Comment 28 Commit Notification 2020-02-08 15:25:17 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9c9f76dd5b6fb115e521ac6568673c7a10879192

tdf#130478 add direct dash paint in cairo

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 29 Armin Le Grand 2020-02-08 21:53:16 UTC
Adapted 5f61c9fe99ac93087b898adddbb4d4733f1fcd07 to branch distro/collabora/cp-6.2, see https://gerrit.libreoffice.org/c/core/+/88284. Was quite some work ;)

Also needs to be adapted, but I was not sure if I can do two cherry-picks in one run: 9c9f76dd5b6fb115e521ac6568673c7a10879192
Comment 30 Armin Le Grand 2020-02-11 18:34:55 UTC
Added for Win: see https://gerrit.libreoffice.org/c/core/+/88463 - not that straightforward as it seemed :(
Comment 31 Armin Le Grand 2020-02-11 18:40:20 UTC
@Stuart: checked that doc - problem seems more to be the gradients. Loads well with my version here, need to compare with older...
Comment 32 Armin Le Grand 2020-02-11 19:05:18 UTC
@Stuart: okay - installed a product version reading

Version: 6.4.0.3 (x64)
Build-ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU-Threads: 8; BS: Windows 10.0 Build 18362; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: CL

and tried to load image5.emf - gave up :( With this change. I can just load it :-) Maybe in-between someone added a fix already - else, indeed this one solves it...
Comment 33 V Stuart Foote 2020-02-11 19:45:39 UTC
(In reply to Armin Le Grand from comment #32)
> @Stuart: okay - installed a product version reading
> 
> Version: 6.4.0.3 (x64)
> Build-ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
> CPU-Threads: 8; BS: Windows 10.0 Build 18362; UI-Render: GL; VCL: win; 
> Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
> Calc: CL
> 
> and tried to load image5.emf - gave up :( With this change. I can just load
> it :-) Maybe in-between someone added a fix already - else, indeed this one
> solves it...

Not sure. I think we had a typo in one of Chris's commits, as result started to bypass use of a dashed pen for the EMF+ (EmfPlusPenDataDashedLine) instead treating it as a mitered line. See https://bugs.documentfoundation.org/show_bug.cgi?id=129675#c15

Fixing that may still be needed to restore the dashed lines in EMF+, but hopefully without the recursive calculations you've tweaked.  @Chris?
Comment 34 Commit Notification 2020-02-11 20:11:05 UTC
Armin Le Grand (Collabora) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c3e098483f4db12e9502c6cbc056e3d7498b7b6c

tdf#130478 add direct dash paint in GDIPlus (win)

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 35 Armin Le Grand 2020-03-06 19:24:04 UTC
(In reply to V Stuart Foote from comment #33)
> Fixing that may still be needed to restore the dashed lines in EMF+, but
> hopefully without the recursive calculations you've tweaked.  @Chris?

Anything o this? Stuff like that should possibly be taken back now - if it works :)
Comment 36 V Stuart Foote 2020-03-06 20:02:31 UTC
(In reply to Armin Le Grand from comment #35)
> Anything o this? Stuff like that should possibly be taken back now - if it
> works :)

Hi Armin,

Sorry, but I'm unable to check it still. The last TB 77 Windows build of master from 2020-02-14 just missed your https://gerrit.libreoffice.org/c/core/+/88463 commit. I've been waiting on a Windows TB build to roll.

@Chris, are you able to take a look at a Windows build of master since 2020-02-15 to check attachment 156837 [details] from bug 129675, and does the bitwise pen type for the EMF+ dashed line still need a fix?
Comment 37 V Stuart Foote 2020-03-07 08:30:46 UTC
Created attachment 158461 [details]
clip of the area with what should be dashed lines

(In reply to V Stuart Foote from comment #36)
>...
> the bitwise pen type for the EMF+ dashed line still need a fix?

sorry forgot that Xisco already tweaked this with
https://gerrit.libreoffice.org/c/core/+/88878

Now Cloph has tb77 rolling Windows builds again (lingering issues with the VS config).

And while no hang when loading EMF+ attachment 156837 [details] on a current master it does not render the 4 arcs as dashed lines. So not sure we are fully correct yet. Opening the EMF with 6.4.1.2 release still chokes.

Attaching a clip of the problem lines the EMF+ as being rendered with current master. If all were correct would expect them to be rendered dashed at reasonable line width.

=-testing-=

Testing Windows 10 64-bit en-US (1909) nVidia GTX 750ti
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 10e20a77ce302a0475a661ad1886f2ca83c55f3f
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster (or Vulkan); VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 38 Armin Le Grand 2020-03-10 09:08:38 UTC
Hi Stuart,

skia backend still transforms and tiles the full PolyPolygon - sigh. No support yet to render dashing in skia directly. Backends that do this are Cairo and Windows (currently). It's missing and I would not recommend to enable skia as default in the current state (also no buffering and no transformation usage for other stuff).
tdf#130655 offers a better interface to dash decompose in basegfx (but not yet used) and hard-limits it to a maximum (plus warning), so that should trigger when too much data created.
Comment 39 V Stuart Foote 2020-03-10 14:04:54 UTC
(In reply to Armin Le Grand from comment #38)
> skia backend still transforms and tiles the full PolyPolygon - sigh. No
> support yet to render dashing in skia directly. Backends that do this are
> Cairo and Windows (currently). It's missing and I would not recommend to
> enable skia as default in the current state (also no buffering and no
> transformation usage for other stuff).

@Luboš, should we back away from a Skia default [1] on Windows, needing to refactor here first?

> tdf#130655 offers a better interface to dash decompose in basegfx (but not
> yet used) and hard-limits it to a maximum (plus warning), so that should
> trigger when too much data created.

Then IIUC at least for EMF+ rendering we no longer decompose the line to dashes in default GDI, or skia rendering--only attempting to do it with OpenGL rendering (see also bug 129675)?  "Simple" dashed lines, eg. borders of draw shapes, seem unaffected.

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/89549
Comment 40 Luboš Luňák 2020-03-16 11:50:36 UTC
(In reply to V Stuart Foote from comment #39)
> (In reply to Armin Le Grand from comment #38)
> > skia backend still transforms and tiles the full PolyPolygon - sigh. No
> > support yet to render dashing in skia directly. Backends that do this are
> > Cairo and Windows (currently). It's missing and I would not recommend to
> > enable skia as default in the current state (also no buffering and no
> > transformation usage for other stuff).
> 
> @Luboš, should we back away from a Skia default [1] on Windows, needing to
> refactor here first?

The Skia drawing is based on the OpenGL drawing, so if something is missing in Skia, it's been missing also in the previous Windows default => there's no regression. Moreover I do not see here anywhere any description of the impact or significance of these changes, so what exactly is the basis for that suggestion?

The point of Skia being the Windows default now is to get more testing. Whether it should stay the default for an actual release can be evaluated when that time comes, and this way there'll be more data to base that decision on.
Comment 41 V Stuart Foote 2020-03-24 22:44:18 UTC
(In reply to Luboš Luňák from comment #40)

> > @Luboš, should we back away from a Skia default [1] on Windows, needing to
> > refactor here first?
> 
> The Skia drawing is based on the OpenGL drawing, so if something is missing
> in Skia, it's been missing also in the previous Windows default => there's
> no regression. Moreover I do not see here anywhere any description of the
> impact or significance of these changes, so what exactly is the basis for
> that suggestion?
> 
> The point of Skia being the Windows default now is to get more testing.
> Whether it should stay the default for an actual release can be evaluated
> when that time comes, and this way there'll be more data to base that
> decision on.

Yes that is probably correct--the rendering of dashed lines in EMF+ affected OpenGL as well, removing this from the Skia META...
Comment 42 Luboš Luňák 2020-05-27 13:00:15 UTC
https://git.libreoffice.org/core/+/3a93748c9c4faadeb9ab4eb21706d187677549fa%5E%21 and the follow-up https://git.libreoffice.org/core/+/dbcf176d8ac1945b8f1e3c95d1401d0f1f85584d%5E%21 implement line in the Skia VCL code by directly using Skia to do the dashing, so I consider the Skia part of this bugreport done.
Comment 43 V Stuart Foote 2020-05-27 14:17:09 UTC
@Luboš, *

Cool, looking at attachment 156837 [details] (an EMF+ with dashed arcs) inserted onto a Draw canvas today's TB77 build.

With default GDI rendering, The Purple colored arc does pick up a line weight, but not dashed. The other three Arcs take default weight and are not dashed.

With Skia rendering enabled two of the Arcs --SkyBlue & Orange-- get a reasonable line weight and do have a dashed attribute. But dashes are only apparent with Zoom in > ~350%

No change to the Purple arc, same weight still not dashed. And the Green arc gets missed, and keeping only a default line weight without dashes.

Same effect with Skia with Vulkan or raster rendering.

So, line weight is good but the length/positioning of the dashes seems unmanaged. Is that still going to be against Skia? Or, with the EMF import filter not giving those details?


=-testing-=
Windows 10 Home 64-bit en-US (1909) with
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 0a7341c26741f16835c9062c309e7d3a7fca8209
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

and
RenderMethod: vulkan
Vendor: 0x8086
Device: 0x5916
API: 1.2.135
Driver: 0.401.4091
DeviceType: integrated
DeviceName: Intel(R) HD Graphics 620
Blacklisted: no
Comment 44 Luboš Luňák 2020-05-28 08:15:42 UTC
(In reply to V Stuart Foote from comment #43)
> So, line weight is good but the length/positioning of the dashes seems
> unmanaged. Is that still going to be against Skia? Or, with the EMF import
> filter not giving those details?

 I checked what result several different VCL backends give, and none of those seem to match exactly how the EMF is rendered in Windows. And, AFAICT, Skia code renders the dashing exactly show it's told to (also using the visualbackendtest tool in VCL, Skia renders the dashing test there the best, compared to other backends). So until proven otherwise, I take it that any remaining problems are in the handling of the EMF itself.
Comment 45 V Stuart Foote 2020-06-01 15:27:01 UTC
(In reply to Luboš Luňák from comment #44)
>...
>  I checked what result several different VCL backends give, and none of
> those seem to match exactly how the EMF is rendered in Windows. And, AFAICT,
> Skia code renders the dashing exactly show it's told to (also using the
> visualbackendtest tool in VCL, Skia renders the dashing test there the best,
> compared to other backends). So until proven otherwise, I take it that any
> remaining problems are in the handling of the EMF itself.

Version: 7.1.0.0.alpha0+ (x64)
Build ID: a0c90f1bccd9b5a349d3199746facab549f27dba
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

With https://gerrit.libreoffice.org/c/core/+/94961 applied (it is not in the 7.0.0 Beta1 release build), three of the dashed line arcs are well rendered. Just the Green arc above the "SE" button is un-dashed. Likely an EMF issue.

Agree the Skia part is working well!

The killer EMF+ of attachment 156837 [details] is no longer choking recursively with the other render engines, but the dashes there are still not quite right either.
Comment 46 Xisco Faulí 2021-02-09 14:38:24 UTC
Dear Armin Le Grand,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assign it back to yourself if you're still working on this.
Comment 47 How can I remove my account? 2021-08-31 08:25:39 UTC
Was the promise "that is for working purposes only and will be removed later/before master" forgotten?
Comment 48 Gabor Kelemen (allotropia) 2023-04-14 09:34:40 UTC
*** Bug 127134 has been marked as a duplicate of this bug. ***