> swapping would make these few things required) rather than introducing > special window. You can for instance draw everything using standard > device (recent implementation of drawings) and use caito only for parts > which would you want to draw it more precisely or you want tu use cairo > features which fltk does not have (yes, as a bonus you have all cairo > primitives)s. Swapping is an option indeed,but for users that would like to use cairo for what they can't do with classic drawing interface (that's really how I see cairo optimal use in fltk), they may not even need swapping, just a cairo subwindow in an fltk window and no swapping hassle.
Now if you also want an 'awesome' gui interface, one could use cairo to render into an offscreen buffer or a png image, then cache this image and clip it to the size of the widget, and the trick is done! That's one thing I have in mind for months and that could give a cool cairo scheme for fltk1 *without* fltk internals modifications ... > > This said, providing fltk pluggable rendering certainly is a desirable > > thing, but I don't know what would be the performance cost of such > > indirection into the fltk drawing engine. > > I believe not too much. I have implemented abstraction once using > virtual functions(see Fl_Device in the baasar). Although calling a > virtual function instead of ordinary one adds a small overhead (digging > through vtable and doing some additional dereferencing), from what I Not only IMHO, the new architectured api itself may require a bit more instrumentation/decomposition for providing the genericity required for pluggable layers, but I would certainly agree it would be neglectable compared to the cairo overhead. This said, my concern was more about non cairo surfaces, but it may be acceptable. Fabien. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
