kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #32044
Re: Some tests.
-
To:
Heikki Pulkkinen <hei6mail@xxxxxxxxx>, kicad-developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>
-
Date:
Wed, 29 Nov 2017 00:32:42 +0100
-
Authentication-results:
spf=pass (sender IP is 188.184.36.48) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
-
In-reply-to:
<CAL5d-KUdgAJ=WgzkXn6vXuLdzdpCjWmrHd=dT5NStYLECkRCGQ@mail.gmail.com>
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
On 28/11/17 18:25, Heikki Pulkkinen wrote:
>
> Zones filling new record with new connectivity algo with A64-Olinuxino
> board. 13s.
Heikki,
I would be very glad to include your improvements in the zone filling,
but the code you've sent to me (your Github) does not meet the quality
standard we expect:
- It's a mix of object and non-object oriented code which is diffucult
to understand.
- It doesn't follow Kicad coding style rules.
- It contains much more than faster zone filling, everything is mixed
with your via stitching/thermal code that we did not accept for the
reasons we had already explained to you.
I also investigated why the zones are filled slowly - the major reason
was a bug in the GAL zone filling algorithm, which was filling all zones
by performing N independent fills of every zone causing the isolated
copper islands to be checked N times (where N=number of zones in the
design) instead of just once. The branch [1] contains this bug fixed. It
also introduces quite a speedup in zone loading/rendering and
parallelizes all zone filling operations using OpenMP. It refills all
zones on the "A64-Olinuxino
board" in less than 3 seconds and something around 10s for the "wrs"
board on a Core i7-4700MQ, 16GB RAM machine.
Please, if you want to be a member of Kicad developers, follow some rules:
- Ask before making heavy changes. Connectivity algorithm is an example
of a heavy change.
- Don't introduce large or risky changes in your first patches. Changing
the file format is an example of a potentially risky change that should
be consulted with other developers.
- Announce you're working on something before you start writing the
code. Someone else may be already working on this part - which is what
exactly happened with the connectivity algorithm
I'll be very happy to have a look at your teardrops and automatic zone
stitching code - which IMHO is an very valuable addition to Kicad -
after the V5 stable release is out.
Cheers,
Tom
[1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones
Follow ups
References