Fabien Costantini wrote: > Matt wrote >> Who can architect this? >> >> What we would need IMHO is hand full of virtual classe to create a low >> level interface between FLTK and the OS libraries. On the one end, >> FLTK can be modified and extended without any machine considerartions, >> and on the other end of those (four or so) classes would the hardware/ >> OS interface live. >> >> If that interface is complete and well defined, optionally pluggable, >> we can support Cairo relatively easily. If compatibility is a concern, >> an App can be started with the X11 backend. If antialiasing is needed, >> Cairo is the backend of choice, and for speed OpenGL would be a nice >> base for a GUI. We would gain framebuffer support as a side effect. >> >> The minimum hardware layer for FLTK is coloring of a pixel, a timer, >> and a mouse or touch event. If we can reduce the interface to that >> level, we can build up from it and provide a GUI to pretty much >> anything that has pixels. > If I understand you, it correspond more or less to a discussion we had many > years ago about providing pluggable rendering layers to fltk. > In this perspective, the Cairo implementation would take in charge all > drawings when selected as the default rendering layer. > > This idea is quite appealing and I think feasible for many layers (i.e for > win32:GDI,DirectX,OpenGL ; for os x Quartz,QuickDraw, etc ...), but from my > humble experience of fltk2, it seems to me than Cairo was not a good choice > for a complete drawing layer for many reasons, previously discussed. > > What has been discussed first here was instead the possibility to incorporate > cairo code into fltk easily. > An element of answer I proposed was to create a Fl_Cairo_Window class similar > in a way to a Fl_Gl_Window, as Ian pointed out.
Actually I did quite lot cairo experimentation and you can pretty well mix cairo code with the ordinary fltk drawing calls as long as you do a few things during swapping. So if you do the device abstraction (I did that on couple of occasions), you can just swap the current device (this 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. Also printing is then much easier: you can draw everything using standard drawing (it is muuuuch faster than cairo, believe me) and for printing swap to cairo device, redirect the cairo to the printer or file(using ps, pdf, svg, png backend or whatever cairo supports) and you can print any fltk widget (group, ...) Yo can even introduce special Fl_Printer device (which would use cairo as a backend) which could do additional page formating/placement etc. > 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 did some "amateur" tests, one virtual call was still cheaper than two ordinary "C" ones - but might be compiler dependent. Comparing to cairo it would be "lost in the noise" - cairo usually does quite a lot of subcalls and additional work even for the simplest primitives before it reaches the actual drawing code. R. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
