[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-dev: PCB + GL (For your amusement)
Hi Peter,
After running ./autogen.sh and ./configure --enable-maintainer-mode it
spews:
<quote>
checking for GTKGLEXT... configure: error:
*** Required version of gtkglext is not installed - please install first
***
Please review the following errors:
No package 'gtkglext-1.0' found
</quote>
rpm -qa|grep gl only gives (amongst others):
gtkglext-1.2.0-3.fc5
So installing the usual suspect: gtkglext-devel-1.2.0-3.fc solves this.
After running make I get:
hid/gtk/gtkhid-main.c:36:21: error: GL/glut.h: No such file or directory
Installing freeglut-devel-2.4.0-4 (another usual suspect) solved this
one.
Make seems to have badgered though the code and have made it, it's now
installing footprints :)
It seems to take forever on a 500 MHz P3 with 320 MB RAM :(
footprints I will never use anyway, can't we just disable them
using ./configure --disable-footprints or something ?
To be seen at:
http://www.xs4all.nl/~ljh4timm/downloads/pcb-OpenGL-screenshot.png
Just my experiences on the subject.
Kind regards,
Bert Timmerman.
On Sun, 2008-06-15 at 13:27 +0100, Peter Clifton wrote:
> On Sat, 2008-06-14 at 23:33 -0400, Joshua Boyd wrote:
> > On Jun 14, 2008, at 9:06 PM, Peter Clifton wrote:
> >
> > > This is generally a bit crufty, but for your amusement, see the
> > > attached
> > > patch. It breaks drawing the mask layer, cursor and rubber-band lines,
> > > but is a stab at making PCB render (translucent drawing) with GL.
> > >
> > > Its frame-rate on my complex power controller board at minimum zoom is
> > > about 2.4 frames per second. This basically matches the frame-rate
> > > of my
> > > similarly crufty test implementation with cairo.
> >
> > I do not at all have the time to try to put together a build
> > environment for this (I've been using the Motif version on Solaris).
> > If someone had notes on what all I'd have to install to be able to
> > build it, I might get around to trying it.
>
> Thanks for looking, I'm not sure exactly what is required. It will
> basically be the libraries needed for the GTK version (GTK, GLib etc..),
> plus GtkGlExt, libGL, libGLU.
>
> > However, reviewing the patch (applying the patch and reviewing that
> > would probably be better still), I have a few suggestions that may
> > help speed. Some of these suggestions may only help specific chips,
> > and they may all be outdated for the latest and greatest hardware.
>
> Hmm... it appears I have been an idiot, and sent the wrong patch. Sorry
> for the wasted review effort. (Although various of the comments still
> apply). Try this attached one..
>
> > First, in ghid_draw_line, you are setting the shademodel and the
> > material attributes and setting up light and doing some enables.
> > These only need to be done if you have turned them off elsewhere. I
> > don't see anyplace that you disable GL_LIGHTING, GL_LIGHT0, or
> > GL_DEPTH_TEST, so you don't need to do the enable every single line.
> > Likewise with the shade model, material attributes, and light. Your
> > OpenGL may be smart enough to not make unneeded state changes, but
> > doing the check will still waste some performance. Also, I could be
> > wrong, but I don't think you need to reinit gobj every time.
>
> I've still got that, I'm not sure how much overhead is associated with
> gluNewQuadric(), my profiling showed hotspots in actually flushing
> commands in the GPU ring-buffer.
>
> > Second, don't use glVertex3f when you can use glVertext2f. This will
> > at least help the C performance even if it doesn't make a difference
> > to your graphics card. That said, I suspect that while an Nvidia
> > card always does a 3D transform, the OpenGL library for Intel
> > graphics may be smart enough to only do 2D transforms sometimes.
>
> I'm not sure, but what does it take the Z-coordinate to be if we don't
> specify it? (Does it stay at the last Z vertex value, 0)?
>
> > Third, if you want a spinning 3D view, make that a special mode.
> > Otherwise, turn off lighting and depth testing. That will especially
> > help performance on platforms with a CPU transform system.
>
> Done, and I've tidied up the patch I should have sent in the first
> place.
>
> > After those things, if you really want to make it fast, you need to
> > drastically change the line drawing methods. To my understanding, a
> > lot of what is contained in this:
> > http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html
> > will apply to most platforms.
>
> I'll have a read, thanks! Its the line caps and vias etc.. which seem to
> harm the performance so far. gluDisk etc.. I clawed some of that back by
> using less slices.
>
> > They mention vertex buffer objects,
> > that I think that may not be the most backwards compatible, but I
> > don't know how far back you want to support. Personally, I like to
> > keep 1.2 supported as much as I can. I'd hold out for 1.0, but
> > working with textures in 1.0 is too painful.
>
> Is that the same as vertex lists? That might help if we can stamp out
> the same triangles again and again for doing vias and pads etc., but
> we'll have to add some some caching mechanism.
>
> --
> 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-dev mailing list
> geda-dev@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev