Hi Peter and all, Now if we could only print the silk on top of the mask and not underneath it, this OpenGl version would be really bling bling :)
Look at: http://www.xs4all.nl/~ljh4timm/downloads/pcb-OpenGL-screenshot3.png Would it be an idea to modify this patch into a OpenGL-HID version ? Kind regards, Bert Timmerman. On Sun, 2008-06-15 at 16:12 +0200, Bert Timmerman wrote: > 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 _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
