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. This window class would map the cairo surface to an os target window and make possible to achieve cairo rendering in it. The big difference is that we would keep the things simple and fast even when dealing with Cairo as the existing drawing functions of the toolkit would remain untouched. I could see rapidly what I can do in that direction if it is desirable. Note that this much more humble idea is not incompatible with a full fltk cairo rendering solution, itself integrated into a pluggable layers architecture, but is IHMO more realistic in the short/mid term than a full cairo integration + other layers integration. 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. Fabien _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
