Delay initializing router with complex copper footprints

[Konstantinos Halakatevakis]

There is a annoying delay when start placing or dragging a track.
Please see attached image.
I have noticed it in both my home and work computer.
Actually, in my work computer the lag is very big, about 10 seconds.
I have Windows 10 64 bit in both machines.
In previous versions everything was OK.

Application: kicad
Version: (5.1.0)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Tomasz Wlostowski (twlostow)]

Send us the board please :)

[Konstantinos Halakatevakis (kosthala)]

I made a few tests and i realized what is the problem.
In my board i have import two dxf hatches and it seems that is the problem.
I have attached a demo board in order to recreate the track delay.

[Seth Hillbrand (sethh)]

Until we address this issue, the easiest workaround would be to change the DXF hatch to avoid the rounded corners.

[Tomasz Wlostowski (twlostow)]

I don't consider this a bug, it's just the complexity of the geometry of a DXF imported as a footprint that makes the router behave slowly.

@kosthala: why do you need to import hatched zones through DXFs? Would hatching zones directly in Kicad solve that for you?

[Konstantinos Halakatevakis (kosthala)]

I think that Kicad does not support hatching zones yet...only solid filled zones.

[Tomasz Wlostowski (twlostow)]

@kosthala @jpcharras Jean-Pierre wrote a patch last year that enables hatched filled zones. Search for the subject "[RFC] Experimental grid pattern in zone fill" on the developer mailing list. Since we're in the V6 development cycle now, this might get merged sooner or later.

[jean-pierre charras (jp-charras)]

I am waiting for the green light from Wayne to commit the hatched filled zones.

[Wayne Stambaugh (stambaughw)]

@JP, the last I heard you were looking at some performance issues. If it's ready to go, please post the patch on mailing list so we can review and test it. I would like to test it again. It's been a while since you posted the original patch and I need to refresh my memory.

[jean-pierre charras (jp-charras)]

@Wayne,

I attached a revised patch, build against the lasted Kicad version.
I fixed some issues, due to kicad code change.

About calculation time issue, it mainly due to the fact a grid pattern generates a lot more vertices in filled areas polygons.

I found and fixed a few useless zone filling rebuilds, and especially useless polygon fracturations (made twice during zone filling).
The main calculation time issue is due to zone refill calculations.
When filled areas polygons have a lot of vertices, the polygon fracturation can take a while.
I am guessing polygon operations are O(n) but fracturation is O(n*n)

I am also expecting grid patterns are not used for large and complex zones, and not for grid having a very small size, so the calculation time is acceptable in many reasonable cases

[Wayne Stambaugh (stambaughw)]

Now that pcbnew supports hatched zone filling, would the status of the bug report be "Fix Committed"? I don't know what else there is to fix.

[Michael Kavanagh (michaelkavanagh)]

Seems sensible (this bug has a low heat anyway). Please reopen if there is still an unsolved issue.