Looks like my ever-slowing frame-rate on my logic-board is due to the addition of (many) polygons during the final stages of the design process. After disabling ALL drawing operations, PCB was only reaching a throughput of of about 1.7 fps.
Reaching for the profiler, it appears that the polygon dicer is to blame. The profiling showed an obvious hot-spot copying polygons to feed into the no-holes tesselator. "poly_CopyContour" calls "make_edge_tree", which is taking a lot of time in "__r_insert_node". Since the high-level concept for this operation is "copy an existing polygon", presumably we already have a valid r-tree structure which we could deep-copy (and adjust pointers?) as necessary? Oddly, just replacing: (*dst)->tree = make_edge_tree (*dst); with: (*dst)->tree = NULL; Didn't appear obviously detrimental to rendering. (May have broke other things, but I didn't test extensively). So this presents a few options.. 1. Fix the dicer / contour copy / r-tree code to be faster. (Probably beyond my expertise) 2. Cache diced polygons. I implemented this, and it helps rendering speed at the expense of extra "bootup" time loading my design. (Which took several seconds anyway). 3. Dispense with polygon dicing for the GL version.. the GLU tesselator can cope with holes, I just need figure out how to get that raw data into the GUI. OTOH: It is somewhat frustrating to use the GLU tesselator. Its "combine" callback function has to allocate memory for new vertices, and it is not very convenient to stash the required list of pointers to free after GL is done with them. (For now, I leak that memory, leading to a growing memory footprint with redraw activity). The internals of the tesselator (according to my profiling) appears to spend a reasonable time in malloc itself. I have to feed it vertices one by one, which is giving a non-trivial overhead. (One screen repaint is producing several thousand, if not tens of thousands of vertices). Could we add functionality to the PCB polygon code to allow tessellation into triangles (or convex polygons), so we can cut out the GLU tesselation step? Regards, -- 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
