kicad-developers team mailing list archive

[Seth Hillbrand <seth.hillbrand@xxxxxxxxx>]

Hi Jeff-

By DRC, I meant the DRC problems/markers.  The unconnected count, like the
status bar count, is based on the connectivity search that this patch
affects.

As you note, the unconnected count has been potentially different between
the status bar and the DRC dialog.  This was primarily an issue in the v4
connectivity algorithm that Tom fixed last year.  There are still a couple
of corner cases that are corrected by DRC fully clearing and re-building
the connectivity net and some that are not.

The proposed patch modifies how we do the coarse check but not how we do
the fine-grain check.  In other words, this does not change how we
determine that items are definitely connected.  It does change whether we
check that a specific pair of items are definitely connected.

The coarse check is changed from an x-axis proximity of the anchors to a
rectangular bounding box collision between the full items.  One side-effect
of the patch is to make the unconnected count more accurate by checking for
connections between tracks and other items (tracks/vias/pads) where the
anchors are are separated than the search proximity but the track crosses
the item's anchor.

-S

Am Di., 29. Mai 2018 um 13:36 Uhr schrieb Jeff Young <jeff@xxxxxxxxx>:

> Since you say it doesn’t impact DRC I assume you mean the status bar
> unconnected count rather than the DRC unconnected count.
>
> FWIW, we recently renamed the status bar on “unrouted” because it’s
> already known to be less accurate than the DRC unconnected count (even
> before any of Seth’s changes).
>
> On 29 May 2018, at 17:59, Seth Hillbrand <seth.hillbrand@xxxxxxxxx> wrote:
>
> Am Di., 29. Mai 2018 um 08:55 Uhr schrieb Wayne Stambaugh <
> stambaughw@xxxxxxxxx>:
>
>> On 5/28/2018 11:21 AM, Tomasz Wlostowski wrote:
>> > On 25/05/18 18:53, Seth Hillbrand wrote:
>> >> Hi Tom-
>> >>
>> >> For a particularly large board I'm working on (32 layers, 124k tracks),
>> >> current master takes 2.4s per connectivity update (clicks, moving
>> >> footprints, enable layers, etc).  With the patch, connectivity search
>> is
>> >> 10ms per click.
>> >>
>> >> I did a merge with your tom-background-connectivity branch but I needed
>> >> to rebase it to master before doing that.  The conflicts were with
>> >> inserting the aWorker-CheckInterrupt() conditional in the itemList
>> search.
>> >>
>> > Hi Seth,
>> >
>> > I don't plan to use the background connectivity branch before 6.0 (as
>> > it's incompatible with the legacy canvas). Your R-Tree patch though
>> > looks very nice. I vote for merging it if Wayne's OK.
>>
>> What's our risk exposure here?  I didn't get a chance to look at the
>> patch over the weekend.  If the risk is low, then I'm OK with merging it
>> but we need to have high confidence.  Otherwise, we should push it off
>> to the first v5 point release so we can get some additional testing.
>>
>
> ​The risk surface for this patch is in the unconnected count.  This
> doesn't impact DRC or file generation.  Unconnected count risk is primarily
> in the negative (we list it as unconnected but it is really connected) as
> this doesn't change the item<->anchor HitTest routine.  That said, the
> expected change in unconnected count is zero.
>
> I've gone through my library of designs and a few from GitHub and don't
> find issues but I would appreciate if someone had a chance to run this and
> look for any discrepancies in their boards.
>
> -Seth
>
>
>> >
>> > Tom
>> >
>> >> -S
>> >>
>> >> Am Fr., 25. Mai 2018 um 08:35 Uhr schrieb Tomasz Wlostowski
>> >> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>>:
>> >>
>> >>     On 25/05/18 05:16, Seth Hillbrand wrote:
>> >>     > Here's an updated patch for working with large, complex boards
>> in v5.
>> >>     >
>> >>     Hi Seth,
>> >>
>> >>     Thanks for the patch.
>> >>
>> >>     How much faster is it compared to the current master branch?
>> >>
>> >>     > Tom, I took your advice and put a light layer over an RTree for
>> the
>> >>     > connectivity search.  Since this gets us bounding box collisions,
>> >>     we can
>> >>     > do commutative hits by using both items in the collision,
>> eliminating
>> >>     > the need to iterate over the full list.
>> >>
>> >>     Great!
>> >>     >
>> >>     > I also did a test merge with your dev tree and had only a couple
>> minor
>> >>     > conflicts, so I think our approaches will compliment well.
>> >>
>> >>     Did you try to merge it with tom-background-connectivity branch?
>> >>
>> >>     Tom
>> >>
>> >
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>