Mail Archives: geda-user/2018/05/11/04:33:02
Hi Michael,
this is the dash freq test - thanks in advance:
On Tue, 8 May 2018, gedau AT igor2 DOT repo DOT hu wrote:
> 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
>
>
- Raw text -