[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-dev: PCB + GL (For your amusement)
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
> > 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
_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev