| ID: | 2630 |
| From: | ge...@igor2.repo.hu |
| Date: | Thu, 31 Jan 2019 06:13:51 +0100 (CET) |
| Subject: | Re: [pcb-rnd] poly clipping performance optimization (was Re: Bug: |
| in-reply-to: | 2624 from Gabriel Paubert <pa...@iram.es> |
| replies: | 2633 from Gabriel Paubert <pa...@iram.es> |
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. 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? 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. 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). >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.
Reply subtree:
2630 Re: [pcb-rnd] poly clipping performance optimization (was Re: Bug: from ge...@igor2.repo.hu
2633 Re: [pcb-rnd] poly clipping performance optimization (was Re: Bug: from Gabriel Paubert <pa...@iram.es>