kicad-developers team mailing list archive

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