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 <j...@rokeby.ie> 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 <seth.hillbr...@gmail.com> 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 <j...@craftyjon.com>: > >> 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 >> >> 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 >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
