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 > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
