On Thu, 2007-11-29 at 14:57 +0000, Peter Clifton wrote: > On Thu, 2007-11-29 at 09:44 -0500, Stuart Brorson wrote:
> Any "demand" to switch coming from my direction would only really come > if I had time to help work on the "why is cairo slower" issue, and even > that could be done via tracking CVS. > > Unfortunately, I think the cairo issue may boil down to waiting for / > providing a faster rasterizer in cairo, their current software > implementation is known to be slower than many others out there. I found some low-hanging fruit.. Gerbv is still mixing old, non-cairo drawing code with cairo. See redraw_pixmap(), and that its being called as well as cairo rendering code. This function is slow. I commented out the mouse icon changing stuff, the pixmap generation stuff, and changed the deprecated: gtk_widget_draw(widget, &update_rect); With: gdk_window_invalidate_rect(widget->window, &widget->allocation, FALSE); This queues a draw from an idle function. We should use this where possible. I realise all is still not quite right, as gerbv also has lots of manual idle function stuff in it. This almost certainly wants to go in favour of the gdk mechanism. I'm not certain which of the above the speed improvement is due to, but it might just be that ...invalidate_rect.. queues a redraw, where gtk_widget_draw() draws immediately. This means with the invalidate_rect, I could zoom faster than drawing keeps up, and it would still feel snappy. My time is limited, but eventually I can work this up into a useful patch. -- 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 geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user