So do we really need the checkbox then? > On 21 Mar 2018, at 00:38, Jon Evans <[email protected]> wrote: > > Stacking up the BOARD_COMMITs was most of the problem. Thanks for the tip, > Seth! > > On Tue, Mar 20, 2018 at 9:52 AM, Jon Evans <[email protected] > <mailto:[email protected]>> wrote: > I will try Seth's performance idea to see if I can make a minimally-intrusive > improvement there. > I was proposing it as an option because (a) it changes the way DRC has always > worked, and maybe some people don't like seeing a million overlapping errors > if they have a track with many segments that all conflict with a pad, for > example, and (b) because it is currently *really* slow, like 10x slower, on > large designs. > > -Jon > > On Tue, Mar 20, 2018 at 9:46 AM, Jeff Young <[email protected] > <mailto:[email protected]>> wrote: > Do we really want a user preference for this? From first blush I'd think it > should report all errors all the time. (And the fact that it doesn’t strikes > me as enough of a bug to want it fixed for 5.0.) > > I think both Seth’s performance ideas are worth pursuing, but probably in > 6.0…. > > Cheers, > Jeff. > > >> On 20 Mar 2018, at 03:38, Seth Hillbrand <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Jon- >> >> I don't see anything inherently problematic here. Works as advertised and >> seems to be minimally invasive. >> >> I suspect that your primary speed bump is the BOARD_COMMIT being called on >> each segment error marker. You might get bang for the buck by conditionally >> starting a BOARD_COMMIT at the beginning of DoTrackDRC in the case where you >> are reporting all errors and commit.add the markers rather than calling >> addMarkerToPcb(). Then push at the end of the function. Also, do we need >> to create undo entries for the DRC markers? I suspect not but I could be >> overlooking something. >> >> All that said, this is a useful addition and definitely speeds up error >> resolution on problematic boards. >> >> -S >> >> 2018-03-19 19:58 GMT-07:00 Jon Evans <[email protected] >> <mailto:[email protected]>>: >> I'd like some eyes on this before I push it, since it's a rather significant >> change. >> >> I have added a (disabled by default) option to report all DRC issues on each >> tested track. The current behavior is to stop at the first error, which >> means that the only way to get a full DRC report is to fix errors one by one. >> >> See: https://bugs.launchpad.net/kicad/+bug/1754442 >> <https://bugs.launchpad.net/kicad/+bug/1754442> >> >> I tried to make this change as minimal as possible because I know the DRC >> code is a target for refactoring after 5.0. The performance of the current >> system is not great, and I can think of several optimizations that would >> help a lot, but I think they would touch too much to be a part of 5.0. >> Fortunately there is progress reporting on this step, so at least users will >> have feedback. >> >> -Jon >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> Post to : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> Post to : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <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
