kicad-developers team mailing list archive

[Seth Hillbrand <seth.hillbrand@xxxxxxxxx>]

Do people have concerns with the risk exposure for this patch or would
anyone like some additional time to evaluate?

-S

Am Di., 29. Mai 2018 um 15:40 Uhr schrieb Seth Hillbrand <
seth.hillbrand@xxxxxxxxx>:

> ​Examples always work better than words.  :)
>
> Here is an example board that incorrectly lists unconnected tracks in
> previous DRC but is correctly listed as connected using the proposed
> patch.  This was created by user eelik on the forums while they were trying
> to copy/paste a specific track layout.​
>
> -S
>
> Am Di., 29. Mai 2018 um 14:59 Uhr schrieb 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
>>>
>>>
>>>