On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: > Peter Clifton wrote:
> Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full > polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia > quadro, closed source driver. > > current HEAD: > full poly: 15 FPS > thin draw: 25 FPS > > version 20091103 as it is distributed in debian/squeeze > full poly: 31 FPS > thin draw: 25 FPS > > Yes, the 20091103 version is faster with full polygons. I'd been developing "polygon_speedup" with the PCB+GL hid in mind, and that does not use the polgon dicer. (It uses a much faster algorithm to split the polygons up for rendering - although one perhaps not as suited for gerber output). I'm a little surprised that the frame-rate during benchmarking is affected though, as there ought to be a "NoHoles" cache. Try this. git fetch git checkout -b test_before_polygon_speedup 323a0c52f7dfdaae51fd7ead87373b3dac90be14 (And build that to compare). This should test whether it is my last committed changes "polygon_speedup" which slowed things down. If it was.. I'll have to take a look. When I built git HEAD PCB before I merged that code, I did notice how glacially slow the rendering was. It is just possible that some other changes since the 20091103 version have caused a performance regression. Not that I'm shouting too loudly, as it might well have been me which caused them ;) There have been 259 commits since 20091103 to today's git HEAD. Lots of regression potential. Might be any of these?: commit 7dc2d854f3e58680577b2bb71cd68b2b769e3025 Author: Peter Clifton <[email protected]> Date: Thu Nov 12 23:54:07 2009 +0000 hid/common: Clip no-holes polygon pieces before calling fill_contour This avoids integer overflow in some HIDs (GTK, Lesstif?) when drawing at high zoom level. Such overflow would lead to incorrectly drawn polygons. It is possible that a similar bug could effect thin-drawn polygons, but that has not manifested its-self so far. If we were to clip these in the future, we need to be careful to extend the clip region slightly off-screen, so the outlines are not drawn. Ideally we would clip these vertices using a Sutherland-Hodgman clipping algorithm, then we could simply discard edges which are clipped completely. commit ede7157be717b4cd22e1e51b6045a2ea5f28de26 Author: Peter Clifton <[email protected]> Date: Fri Nov 13 01:14:08 2009 +0000 hid/common: Control update of NoHoles cache based on clip region If at least 50% of the bounding box of a polygon is within the clip region, compute the whole NoHoles polygon and cache it for later rendering. If less of the polygon is within the clip region, just compute what we need to draw the piece we've been asked for. commit bbe5aa52e540171a08f905e38468623a0d3f2e1c Author: Peter Clifton <[email protected]> Date: Mon May 10 17:40:15 2010 +0100 Fix poly_ContourInContour() test not to return TRUE for touching contours ... (This fix is required for correctness) commit 3d0a8bd1dae0816d364a774bf9b958faf2983ec7 Author: Peter Clifton <[email protected]> Date: Tue May 11 15:55:37 2010 +0100 Speed up poly_ContourInContour() test by computing interior point ... (Attempt to mitigate performance impact of previous patch) commit af2f50d4fb838de13dfbb5243e2114c66fefba7b Author: Peter Clifton <[email protected]> Date: Wed Jun 2 21:09:51 2010 +0100 Fix node_label() function to work with self-intersection > (*): Still not comfortable with the git commands. How do I make absolutely > sure to have the correct branch activated? If you do "git log", you can confirm with me the git SHA1 of the commit you built from. gitk will show you the commit history graphically, if that helps. -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
