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 < [email protected]>: > 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 < > [email protected]>: > >> 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 <[email protected]>: >> >>> 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 <[email protected]> >>> wrote: >>> >>> Am Di., 29. Mai 2018 um 08:55 Uhr schrieb Wayne Stambaugh < >>> [email protected]>: >>> >>>> 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 >>>> >> <[email protected] <mailto:[email protected]>>: >>>> >> >>>> >> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
