[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Rendering code [WAS: Re: next PCB release - 1.99za vs 4.0]



On Fri, 2010-09-10 at 01:00 +0100, Peter Clifton wrote:
> > To do this, we would have to use a single renderer, no? For example, have
> > OpenGL do the viewport drawing in all of Gtk, LessTIF, (Windows?), etc?

Re-reading your comment..

No, we don't necessarily have to use a single renderer. The common code
I factored out was more about the common (current) assumptions about how
to translate from PCB objects to HID drawing calls.

For example, polygons.. 

common_fill_pcb_polygon() {

This routine assumes the GUI can't draw a complex polygon object
natively, and performs quite a lot of computation. (Certainly in my
branch).

If the polygon has a valid cached "NoHoles" (diced) version, that is
used.. otherwise a computation is made to see just how much of the
polygon we're asking to render. If it is > 50% of the polygon area, a
diced version of the whole polygon is computed and cached. If not, just
the area required to be rendered is cached.

The routine then goes on to render the polygon by calling
gui->fill_polygon () with point data representing the various simple
polygons produced by the dicer from the input polygon.

}

There is also a thindraw polygon helper, common_thindraw_pcb_polygon ().
On my branch at least (can't recall if I pushed the change), this uses
an optimisation whereby the polygon code cheats and tracks which polygon
holes are supposed to approximate a circular cutout hole geometry. For
vias cutting power planes, these are quite prevelant, and rendering can
be sped up / improved by tracking this feature. The routine calls
gui->draw_arc (for the circle case), or makes multiple gui->draw_line
calls to render the polygon vertices.

The GUIs / exporters can choose to use the common_* functions in their
HID record, or provide their own implementation. For example, the GL and
postscript output HIDs provide custom "fill_pcb_polygon" routines which
bypass the "common" assumptions about requiring to call
"gui->fill_polygon".

The GL routines use a masking technique to completely avoid needing the
no-holes dicer. Each polygon contour (outer and holes) is rendered by
generating trapezoids, then triangles using a simplified bentley_ottman
rasteriser. The postscript exporter uses the fact that postscript has a
suitable polygon primitive which supports holes.



-- 
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!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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