Improved hatch-pattern support for the drawing add-on

[mozman]

I added a new module ezdxf.render.hatching which brings proper hatch-pattern support.

The branch draw-hatch-pattern adds this feature to the Frontend class of the drawing add-on.

The example DXF file hatch_pattern_iso.dxf in the PyQt CAD viewer:

The line pattern render algorithm has still some quirks (floating point issues), like some missing lines here:

The hatching itself is a simple inside/outside counting algorithm and works for ordinary hatches, but has also some bugs when intersecting collinear edges or corner vertices and so on... :

The CPython implementation is already fast enough and can be speed-up by using Cython, but the backends have more data to handle because every hatch pattern creates many line entities and matplotlib starts to struggle at larger DXF files.

The current hatch pattern support can be removed from the existing backends, everything is done in the frontend and uses only the draw_line() method of the backend. I don't want to support two drawing methods for hatch pattern like for linetypes (see below). The last ressort for big DXF files is to ignore hatches at all or just draw solid fillings (HatchPolicy).

IMPORTANT: The solid hatch drawing has not changed and is still done by the backend!

The same is planned for the linetype support for lines and paths. The backend can use a faster internal linetype rendering if the LinePolicy is APPROXIMATE, for ACCURATE the frontend will pass only solid line segments to the backend, this simplifies the backend and adds linetype support to all backends automatically and existing backends should also work without changes.

[mozman]

The line pattern rendering issue seems to be solved. This was rendered with the Pillow backend which is really fast:

[chibai]

Cool!

[mozman]

@mbway The matplotlib backend is really slow when passing hatch pattern as line segments. Example file "power_unit_1.dxf" from #573. This will make many users unhappy if this will be the default.

Matplotlib backend:

PS C:\Users\mozman\Desktop\Now\ezdxf\573> ezdxf draw .\power_unit_1.dxf -o power_unit.png
drawing Model
took 12.2247 seconds 
exporting to "power_unit.png"
took 29.1356 seconds

overall ~41 seconds

Pillow Backend (uses matplotlib for text rendering as Bèzier curves):

PS C:\Users\mozman\Desktop\Now\ezdxf\573> pillow .\power_unit_1.dxf -o power_unit.png -i 4000
Image size: 4000x4000
DPI: 300
Oversampling factor: 2
Draw text placeholder: False
detecting model space extents (fast=False) ...
... in 0.9s
drawing model space ...
... in 1.9s
exported image to "power_unit.png" in 1.1s

overall ~4 seconds

PySide6 backend without PNG export:

PS C:\Users\mozman\Desktop\Now\ezdxf\573> ezdxf view .\power_unit_1.dxf
using Qt binding: PySide6
drawing Model
took 1.6829 seconds

[mozman]

Found a possible solution, but I have to add new method to the backend draw_solid_lines() which draws a bunch of solid lines at once, this would also solve the same problem for the accurate line rendering by the front end. The default implementation would just call draw_line() for all given lines to be compatible with existing backends:

PS C:\Users\mozman\Desktop\Now\ezdxf\573> ezdxf draw .\power_unit_1.dxf -o .\power_unit.png
drawing Model
took 4.6019 seconds
exporting to ".\power_unit.png"
took 3.5676 seconds

overall ~8.2 seconds

[mozman]

Unfortunately this is not a solution. Matplotlib filters zero-length lines and drawing them as points adds almost all of the time gained back:

PS C:\Users\mozman\Desktop\Now\ezdxf\573> ezdxf draw .\power_unit_1.dxf -o .\power_unit.png
drawing Model
took 10.1692 seconds
exporting to ".\power_unit.png"
took 28.0679 seconds

overall time ~38.2 seconds

[mozman]

Drawing many points at once by the scatter() method is the solution:

PS C:\Users\mozman\Desktop\Now\ezdxf\573> ezdxf draw .\power_unit_1.dxf -o .\power_unit.png
drawing Model
took 4.6123 seconds
exporting to ".\power_unit.png"
took 3.9622 seconds

overall time ~8.6

[mozman]

@mbway The linetype rendering by the frontend is not much slower than by the backend. I could simplify the backends by removing linetype rendering support from them entirely. But this would change the rendering results for current users (@chibai), because I assume most users do not change the linetype rendering method. Any opinions or suggestions?

UPDATE: added a Cython implementation of the LinetypeRenderer() class, which gives a performance improvement of about factor 9.5

[chibai]

May be you can use a FLAG to represent fast rendering and accurate rendering??
But Don't take too much energy on redering part, because this is a Python package for creating and modifying DXF drawings, regardless of the DXF version.

[mozman]

This is the current state by choosing between APPROXIMATE and ACCURATE rendering, the change would remove the APPROXIMATE rendering, leaving the ACCURATE linetype rendering as the only option beside SOLID.

[chibai]

That pretty enough though~~ Creating and modifying is the core function of the project