Delay initializing router with complex copper footprints

Bug #1820493 reported by Konstantinos Halakatevakis on 2019-03-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

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
    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:

Tomasz Wlostowski (twlostow) wrote :

Send us the board please :)

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) wrote :

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

Changed in kicad:
status: New → Triaged
importance: Undecided → Low
summary: - Delay when placing or dragging track
+ Delay initializing router with complex copper footprints
Tomasz Wlostowski (twlostow) wrote :

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?

Changed in kicad:
importance: Low → Wishlist

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

Tomasz Wlostowski (twlostow) wrote :

@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.

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

Wayne Stambaugh (stambaughw) wrote :

@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.


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

tags: added: pcbnew pns
Wayne Stambaugh (stambaughw) wrote :

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.

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

Changed in kicad:
milestone: none → 6.0.0-rc1
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers