| ID: | 2633 |
| From: | Gabriel Paubert <pa...@iram.es> |
| Date: | Thu, 31 Jan 2019 10:12:12 +0100 |
| Subject: | Re: [pcb-rnd] poly clipping performance optimization (was Re: Bug: |
| in-reply-to: | 2630 from ge...@igor2.repo.hu |
On Thu, Jan 31, 2019 at 06:13:51AM +0100, gedau@igor2.repo.hu wrote: > > > On Wed, 30 Jan 2019, Gabriel Paubert wrote: > > >I have attached an example file, which is a small part of the board I'm > >currently designing. With the new brave mode, most operations are now > >reasonably fast. Without the brave mode, I selected P2 (bottom side), > >and simply cut (Ctrl-X) it. Well, I killed pcb-rnd after several minutes. > >In brave mode, it took maybe a couple of seconds. > > Thanks, great! I've tersted it here too (on a much slower mahcine), and I > feel the speedup too. > > Nice board, you are doing real fancy things. I think we should talk more > about what you are doing because there may be features I could add in > pcb-rnd to help your use cases. > > I really like that you have a courtyard layer in your subc! I definitely > want to include official support for that later on, especially with the > new drc. This helps a lot, because the file I sent you is only about 10% of the board. This board is far from finished but there are areas that are fairly densely populated on both sides. In this case, I carefully optimized one instance of vias and differential lines and than simply did a cut and paste for the copies. The messy part was to adapt a connector on an imperial grid to the rest of the board on which all parts with more than 4 pins are metric, while at the same time matching line lengths. > > The grid of vias thing, could that be a subc? It sounds like a convenient > idea to place the connector subc and then place the matching grid-of-vias > subc. Or do you need to edit it a lot, e.g. removing vias? It could be helpful, I have subc (for high frequency chips, where high means up to 20GHz) with lots of via in them. > > I see you also have a lot of differential pairs, I should sit down and do > the extended object infra so you could draw and edit(!) them as pair. In > short: when it's rendered, it'd look like 2 (or N) parallel thin traces, > but when you grab it for editing, it would look and behave like one thick > trace. In the most optimistic case rubber band, route radius, everything > working for the thick version. Then you end the thick version somewhere > and just connect random individual thin traces to the endpoints when doing > the reistor connections. That would be great, and I consider it more important than the grid of vias. > > The hard part is splitting the code: half of the code needs to deal with > the "as edited" version, other half with the "as rendered version". For > example export and connection find clearly needs the as-rendered, which > any buffer operation should use the "as edited". So it won't happen > overnight, but I think it has a great potential (and can solve more than > just pairs/buses). I understand. Up to now I have managed, but this board has essentially 8 copies of the same circuit on one side, 4 copies on the other side. Cut (or copy) and paste really helps, but sometimes it was painfully slow, on a core i7. > > >However an undo (Ctrl-Z) took forever (once again had to kill the > >process), and sometimes ended in a crash, very similar to the crash I > >got with your subc256.lht file. > > Tested this with your board on my slow machine, with the latest fix it > should be good. Indeed, I've not (yet) been able to find a performance issue after these changes. Thank you very much. Regards, Gabriel
Reply subtree:
2633 Re: [pcb-rnd] poly clipping performance optimization (was Re: Bug: from Gabriel Paubert <pa...@iram.es>