X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 8 May 2018 07:15:43 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: Odp: Re: [geda-user] Opengl PCB and mainline PCB - pcb-rnd aspects In-Reply-To: <7c94238102f147ddb327047d3deac362@grupawp.pl> Message-ID: References: <647dca2ad89a4415ad980da6e5cdc701 AT grupawp DOT pl> <7da892c189bd49838d6ce6eb2c2628e4 AT grupawp DOT pl> <7e30777e38284644814271a68f2c2119 AT grupawp DOT pl> <7c94238102f147ddb327047d3deac362 AT grupawp DOT pl> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hello Michael, On Mon, 7 May 2018, michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com] wrote: >I noticed massive speedup when "subcircuits" layer is off. With complete >board benchmark is 8.3, full screen window (single 1600x1200). This is still >slower then opengl pcb (with all layers ON) but we are getting closer. Sounds reasonable: the dashed subcircuit outline is a new feature in pcb-rnd. This is part of the effort to remove "overloading of silk" (see below). I. what to do about this I drew a board with 1024 resistors (1206) on it to measure the effect. You were right, even with gdk sw rendering, the dashed outline drawing slows it down to half the FPS. It's no wonder: those dashed lines are really a lot of short, round cap line segments to draw. The test board is at http://igor2.repo.hu/tmp/1024.lht.gz I've added a new configuration item in r16992, that controls the density of those dashed lines. Setting it to negative turns the dashed bbox off; setting to 0 makes them solid lines; setting them to something between 1..32 draws different dash densities. I could measure considerable differences rendering the same test board at -1, 0, 1 and 5 (the original value). To test this, you need to compile the latest svn version. Don't worry, it's not any harder than compiling 1.2.8 from source - we don't have autogen.sh and maintainer mode or other hacks - the only step that differs is how you get the source. I am not sure if you are familiar with it, so here's the process: 1. svn checkout svn://repo.hu/pcb-rnd/trunk pcb-rnd/trunk (this is the only step that differs compared to working from a release tarball) 2. cd pcb-rnd/trunk 3. ./configure (You probably don't need to use any argument here for gl or gdk or other libs/features - scconfig will simply figure what your system offers and will configure things so you get all features possible and automatically disables things you don't have the libs for - at the end you get a summary on the results so you can check if it did everything right. It will stop only if something mandatory is missing, but pcb-rnd doesn't have too many such dependencies - basically if you have a libc and a c compiler, it already compiles) 4. make Tip: you can run pcb-rnd from source, without installation; this is probably the easiest approach if you are testing new features and experiment with a new version: 5. cd src; ./pcb-rnd There are multiple ways to change the new config setting for the dash frequency. If you like the command line, the easiest is using the following extra argument when starting pcb-rnd: -c appearance/subc/dash_freq=5 If you want to change it run-time, just open the preferences dialog, then open the config PoV subtree, appearance, subc subtree on the left and click on the "dash_freq" entry. You will get a few tables on the right side showing what values are coming from what config sources for this value. Click on the cli row in the table, then edit the numeric value in the entry box on the top right and click on "apply". The result should be visible right away if you pan the drawing area to force a redraw. You can keep the preferences dialog open and keep tuning the value and do benchamrk()s. II. what else to try regarding to this We also have an optional padstack mark: a little cross at each padstack origin. When loading an old .pcb file, pcb-rnd converts all pads and pins and vias into padstacks. In pcb you can't have arbitrary shaped pads, which is often worked around by placing a large number of overlapping pads - which will result in a lot of padstacks, and in turn a lot of padstack marks. If you turn off the padstack marks III. The reasons for the dashed line subc bbox feature With pcb some of us (including me) developed a bad practice to sometimes draw objects onthe silk layer not because we want to have those objects show up on the actual silk screen but on our computer screen. A typical example is when I had a refdes under the component: it won't be visible once the board is built, but it is useful when I look at the board on screen. Another tpical example is drawing the "courtyard" on silk, to help dense packing of parts without overlaps. In pcb there was no other way than to (ab)use the silk layer for this. In pcb-rnd the dashed line is the bounding box of the subcircuit, plus we have a configurable info printout for each subcircuit (which can display the refdes, the value, both, or any other subcircuit attribute, or an arbitrary selection of subcircuit attributes, plus static text, in a single line or in multiple lines). This solves the refdes silk-abuse problem: so we don't need to print the refdes on silk just to be able to see it on the monitor. I can also easily switch to show both the refdes and the value, without overlap, only on-monitor while I am building a board. And then if I need 1% resistors mixed with 5% resistors, I can just add an attribute for this and get that displayed among refdes and value... It also solves the courtyard silk-abuse problem: you can have a virtual "courtyard" layer in your subcircuit, that is never bound to any real board layer (unless you explicitly request a binding). You can draw a rectangle on this layer that is bigger than anything else in the subc, so this will determine the bounding box. (Later on we will have explicit courtyard layers and keepaway layers for various aspects, and then these virtual layers will have a board layer to map to - we have a real strong layer support since early 2017, so extending it witout ugly hacks is easy) Best regards, Igor2