[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: next PCB release - 1.99za vs 4.0
On Thu, 2010-09-09 at 10:17 -0700, Andrew Poelstra wrote:
> > (You may notice I've started in a few places pulling common drawing code
> > into a common_* prefix under the hid/ folder). My aim was to set it up
> > such that the GUIs could take or leave various bits of the common
> > rendering code as their authors desire.
>
> 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?
I started out the GL branch badly... I ripped out the GDK stuff from the
GTK HID, and replaced it with OpenGL code.
Needless to say, that couldn't be committed as was, nor did I wish to
fork the GTK HID and duplicate all the code. So I started to refactor
and teach my new GL code to co-exist with a GDK build. (This effort
isn't yet complete).
I've put much of the core GL drawing routines in hid/common/hidgl.[ch],
exposed API (incomplete), is:
extern triangle_buffer buffer; <--- allows drawing routines to be inlined
extern float global_depth; <--- Nasty hack needs proper API ;)
void hidgl_in_context (bool is_in_context); <-- Debugging GL context validity
void hidgl_init_triangle_array (triangle_buffer *buffer); <-- Initialisation
void hidgl_flush_triangles (triangle_buffer *buffer); <-- Rendering flush (before changing colour etc.)
void hidgl_ensure_triangle_space (triangle_buffer *buffer, int count); <-- Triangle buffer management
static inline void
hidgl_add_triangle_3D (triangle_buffer *buffer,
GLfloat x1, GLfloat y1, GLfloat z1,
GLfloat x2, GLfloat y2, GLfloat z2,
GLfloat x3, GLfloat y3, GLfloat z3); <-- The main drawing primitive
static inline void
hidgl_add_triangle (triangle_buffer *buffer,
GLfloat x1, GLfloat y1,
GLfloat x2, GLfloat y2,
GLfloat x3, GLfloat y3); <-- 2D variant uses global_depth plane
Drawing APIs based on the HID drawing API. Note that some take an extra
"scale" parameter. This passes zoom-level information to the drawing
routines to allow them to adjust the number of elements used when
approximating curved shapes. The GL routines draw in PCB coordinates,
and need varying numbers of triangles to approximate shapes at different
zoom levels.
void hidgl_draw_line (int cap, double width, int x1, int y1, int x2, int y2, double scale);
void hidgl_draw_arc (double width, int vx, int vy, int vrx, int vry, int start_angle, int delta_angle, double scale);
void hidgl_draw_rect (int x1, int y1, int x2, int y2);
void hidgl_fill_circle (int vx, int vy, int vr, double scale);
void hidgl_fill_polygon (int n_coords, int *x, int *y);
void hidgl_fill_pcb_polygon (PolygonType *poly, const BoxType *clip_box, double scale);
void hidgl_fill_rect (int x1, int y1, int x2, int y2);
void hidgl_init (void); <-- Initialise some stuff
int hidgl_stencil_bits (void); <-- Query number of stencil bits available (I think!)
int hidgl_assign_clear_stencil_bit (void); <-- Assign the caller a stencil bit for use, having
ensured the bit-plane is cleared to zero
void hidgl_return_stencil_bit (int bit); <-- Give a stencil back to the pool
void hidgl_reset_stencil_usage (void); <-- Give all the stencil bits back now, and assert
that all stencil bit-planes have been cleared
void hidgl_set_depth (float depth); <-- Set the current depth for planar drawing
The API isn't complete, and a lot of the "clever" / 3D GL stuff I'm
doing needs to move out of custom drawing / setup routines in
src/hid/gtk/gtkhid-gl.c and into a more common place.
src/hid/gtk/gtkhid-gl.c provides wrapper drawing calls for the HID, and
calls into the hidgl versions with any additional data required (such as
zoom). This could perhaps be shared more between GUIs using the common
GL code.
I did a proof-of-concept Lesstif+GL version at one point, but I think
the GTK+GL code-base has drifted a lot since then in terms of
functionality. (Again, it was a drop-in replacement, not a clean
configurable). It did show that the idea could work.
I'm sure the GTK hid on Win32 will work with GL (the GtkGlExt library
has been ported), or even that a native wgl implementation would be
possible.
PS.. have you tried any of the GL stuff?
http://www2.eng.cam.ac.uk/~pcjc2/geda/trans_poly.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-1.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-2.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-3.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-4.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-5.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-6.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-7.png
--
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