On Fri, Apr 20, 2012 at 2:24 PM, Ian MacArthur <imacart...@gmail.com> wrote:

>
> On 20 Apr 2012, at 09:30, james wrote:
>
> > Thanks for the test, it seems that we have lots of work to optimize
> cairo performance. I thought it was just hundreds of times slower in curve
> cases.
>
> Yes - these numbers are really useful. I can't even find the (very crude)
> measurements I made way back when...
>
> It is widely rumoured that the rendering path used by fltk puts Cairo in a
> particularly bad light, so we have to assume that Cairo performance is
> usually much better than this... That said, I don't really know how best we
> go about quantifying that, and determining how fast fltk+cairo could be in
> a more ideal situation...
>
>
I'm still not entirely sure what that ideal situation is supposed to be...

The only thing that's holding me back from trying to render into a
cairo_image_surface instead of a cairo_xlib_surface is that I'm still using
XFT for text. I expect the practical performance of double buffering into
an image surface and using Cairo's 'extents' functionality to avoid copying
anything but the affected areas to the front buffer is probably going to be
better than the current FLTK model regarding the number of actual pixels
pushed through Xlib. But the bottom line is that drawing anything curved
repeatedly is a bad idea with Cairo and the only solution in situations
that require speed is to draw the shape once offscreen and copy it as many
times as necessary. I'm pretty sure this is how most GTK widgets operate
efficiently. This is also going to be true when using the OpenGL backend
etc... It'll only be fast if you're caching everything you draw since
Cairo's antialiasing of curves is so slow.

Having a doublebuffer() property (defaulting to off) on individual widgets
like GTK does would make this easier on the library user in most cases.
I'll probably do this in my fork.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to