> 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. So, hmm, I wonder... When we render text in GL contexts, both the X11 and OSX versions actually render the text into a "cache" the first time the text is rendered, then render it from that cache on subsequent calls (though they appear to use different caching schemes to achieve this - or am I getting confused with the fltk2 X11 GL rendering again? Who knows...?) (Also, note that the WinXX WGL_ methods handle text in GL without this caching scheme.) Anyway, what I was wondering was whether, at least for your use case, it would be feasible to render the Cairo widgets into an offscreen cache on first use, then just blit them into an X11 surface on subsequent calls - overlaying them with XFT text as required? That might give a Cairo-like rendering with XFT text without totally subverting fltk's existing (albeit perhaps non-optimal) render path? Would that work? Might be OK and faster than "pure" Cairo - though would mean subclassing each widget to do the render/cache thing. And might not work at all for that set of your end-users for which offscreen buffers appear to be painfully slow... Just a thought in passing. To be honest, I haven't really thought this through at all, but is *seems* quite attractive on first glance... -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
