On Tue, 2008-06-17 at 21:33 -0400, Dave McGuire wrote: > > I've tried glitz backends for PCB + cairo (still slow), and have even > > tried GL primitives directly for drawing lines in PCB... all are just > > slow with my Intel graphics card. > > I wonder if there's something else going on there. I was writing > GL code (not OpenGL) in 1991, running on a 12MHz (yes twelve) R2000 > CPU with a very simplistic hardware-assisted graphics subsystem, that > threw lines up on the screen so fast it'd make your head spin. Why > would something like OpenGL primitive execution for simple line > drawing be so slow in this day and age?
Glitz - goodness knows what its doing. It looks like it is using software rasterisation for some compositing operations, then texture mapping those into GL. It does give all the cairo antialiased goodness though, and no doubt its possible to extend the rasterisation of polygons to include more compositing oeprations. Raw GL - The line caps produce a lot of triangles, and it is those which hit my performance the most. Joshua Boyd (on the -dev list) said: " As I understand it, your quad takes one buffer flush, while each disk [line cap] also takes a flush, so three flushes per call to that ghid function. If you combine the single quad and the disks as part of a triangle or quad strip, you would reduce your flushing by a two thirds. " I didn't believe this to be the case (thought gl_flush or gl_finish was required to flush the pipeline, other than some ops. which do implicitly flush it), but I don't have documentation either way. I probably need to use vertex lists to make this properly fast. I could probably use the ghid_... callbacks to form the lists, then paint them onscreen after switching each layer. I already had to modify things slightly to make rat-lines transparent, but silk-lines solid. (Ok, I wanted transparent silk, but you can't read it with all those caps overlapping translucently - master plan is to use the stencil buffer and paint a single transparent silk layer, where individual lines making up the silk are already merged together as a solid block). Peter B pointed out that if those vertex lists could be cached for layers which aren't being modified during rubber-banding etc.., we could make it faster still. Best wishes, -- 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-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
