On Sun, 2008-06-22 at 12:38 +0000, Kai-Martin Knaak wrote: > On Sun, 22 Jun 2008 10:27:16 +0100, Peter Clifton wrote: > > > patch -p0 --dry-run < pcb_faster_gl.diff > > > > If it works, take out the --dry-run and repeat. > > Got it working :-) > (after the usual fight with munged line breaks and omitted leading > spaces). Some notes:
Is your email client saving the attachment directly, or treating it as text which it can reformat as it likes? I don't know if anyone else has had problems with patches I've sent, but if it is the case, I'll investigate if my email client is breaking things when sending. I got the impression it attached as a binary file with no modifications. > * On my moderate, but OpenGL enabled hardware there is a serious speed > improvement compared to the current CVS version. A benchmark of my > current layout yields about 35 redraws per second (rps) at a typical zoom > level for manual routing. Polygons were set to thin-draw. Regular pcb > does 12 rps with the same view parameters. When zoomed all out I get 12 > rps with GL and 7 rps without. > With full polygons turned on the redraw rate goes down. But as announced > by Peter, it is a lot better than regular pcb. With GL it is still at 9 > rps while the performance of regular pcb drops to 2 redraws per second. Part of that speedup over the stock PCB case is due to the caching of diced polygons. It doesn't quite work yet (not updating the cached outlines when it should). If I get chance, I'll see what the rendering rates of stock PCB look like with just those changes. > My hardware is a celeron 3000 board with a nvidia FX-5200 graphics card. > I installed the nvidia card specifically because I need OpenGL to get > decent environment for 3D mechanical CAD. However, this is not a state of > the art super gaming card, but a no fan, 128 MB product, which cost me > about 25 EUR. > > * There seems to be an issue with update events connected to gnome > actions. If I have the locate pointer option enabled in gnome > (desktop - gnome - peripherals - mouse - locate_pointer) > the pcb window blanks on pres of [control]. Also, there is no update > during window panning. I'd not checked window panning, but I get the blank window bug. Haven't yet dug into its cause, but likely its due to various event handlers assuming it can initiate paint actions, without going through setting the GL context up properly for use. Similarly, the footprint preview is broken at the moment. > * Currently, tracks on the same copper layer add their alpha channel. > This results in more saturated areas where track segments meet. This > might be useful when looking for tracklets. But during regular routing it > just adds to graphical kludge. IMHO, it is better to regard the whole > track as a single object and don't do transparency between segments. I tried both behaviours and for my work, found the current behaviour quite useful. Sub-compositing layers might be slower / more memory intensive, but I'll give it a go using the stencil buffer. (This is how I draw the mask layer). I would have liked to treat chained up track segments as whole objects, but I don't think PCB stores them in a way which makes that easy. Certainly, the drawing callbacks are just fed a segment at a time. I'm not sure how any of these different approaches stand with the possibility of anti-aliased geometry, but I find it absence less of a visual problem than in gschem. (Must finish the cairo work at some point). I'll also have a poke at anti-aliasing techniques for OpenGL. > I hope, this effort will result in a regular pcb version with OpenGL > enabled. Transparency and speed are significant improvements of usability > with complex boards. Thanks. It was that need which drove me to try it. (I did cairo based rendering / transparency first, but the speed was too slow). I hope to get it merged at some point, and no doubt it will be possible to use the code in the Lesstif HID too (just needs different code to setup the GL context). I'll have to figure out somewhere to put the code where it can be shared usefully between different HIDs. -- 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
