Re: gEDA-user: Building the PCB+GL branch [WAS: Re: Open GL survey (for PCB)]

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Mon, 2009-02-02 at 09:58 +0100, Gabriel Paubert wrote:
> On Thu, Jan 29, 2009 at 03:57:52AM +0000, Peter Clifton wrote:

[snip]

> > If you fancy playing with some other experimental polygon stuff though
> > (again, not yet backwards compatible), try the "master" branch which
> > does full real-time island removal. The broken pieces of "pour" are
> > actually now separate "polygons" internally, so work correctly for
> > electrical connectivity checking.
> > 
> > This allows (for example) one big rectangle fill to work on a board, but
> > allows islanded sections of the fill either to be removed, or be
> > re-connected (not necessarily to the same net), in order that they are
> > kept.
> > 
> > I've still not figured out how to make this work in a backwards
> > compatible way. It much more closely matches PCB's _old_ semantics
> > before Harry introduced computational polygon support. That change broke
> > backwards compatibility with old layouts (which assumed all pieces of 
> > polygon were kept) - I don't want to break anyone's designs again!

> Indeed, and I still keep an old version around since it worked perfectly 
> for my designs, and was _way_ faster on my slow machines.
>
> Actually my question is why was it changed at all? My PCB manufacturers
> had absolutely no problems with the stacked positive/negative mixture
> of layers in the photoplotter files.

I don't think it worked so well when the polygons were on the signal
layers. It also meant that you couldn't do proper island removal or
connectivity checking.

I'm working on this when I've got time, and hopefully we might be able
to get decent performance (possibly not quite the old performance.. but
decent), especially on power planes with just polygons and disjoint
objects such as vias which clear them.

> This said OpenGL is the way to go, even on my desktop (8 years old)
> which gives ~450fps in glxgears (with direct rendering). 
> 
> BTW: I'm actually right now writing a program with OpenGL and am 
> running into bugs with antialiasing on Intel graphics (completely 
> different visual results from ATI or Nvidia boards when enabling 
> antialising). I don't know whether you plan to enable antialiasing
> of not, but we should have the option to disable it if enabled.

I've not switched on anti-aliasing. I think it is important the geometry
has hard edges, and anti-aliasing will just increase memory
requirements / reduce rendering speed. (IIRC, it just renders bigger
than required, then filters the result down).

> Another program which might benefit from OpenGL is gerbv AFAIK.

gerbv was the first program I played with OpenGL in ;)
Actually, I didn't use OpenGl primitives, but was using textured quads,
where the textures were rendered using cairo.

Once I've got PCB sorted, there might well be usefully transferable code
which gerbv could use.


If you've got some spare time, please give the OpenGL PCB branch a try.
I've cured some (not all) of the performance problems encountered with
rendering polygons - your real penalty will be if there is complex
polygon geometry to compute modifications to.


git clone git://repo.or.cz/geda-pcb/pcjc2.git
git checkout -b before_pours origin/before_pours

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user