On 21.02.2010 20:44, Roman Kantor wrote: > The abstraction part is actually very easy and can be done gradually > without breaking fltk core - see my post from 17/11/2009.
Yes, I've seen it. Thanks for all your comments about this and your previous work. The primary conversion from the current function calls to Fl_Device methods looks indeed easy. > The class > need to include also two virtual functions(eg activate()/release()) > which for screen output would do necessary preparation/release of the > drawable and which would be called from within Fl_Window::make_current() > function. They also need to have their own ofscreen() functions for > building the caches. Hmm, that looks more complicated. Especially the offscreen functions are currently problematic, since they are only macros, as you know. > So I would vote to include the abstraction first(as soon as possible) as > keeping recent code inside the default device represents nearly no risk > of break things ... if done correctly and completely w/o forgetting something... > and let people play with their own device > implementations completely *OUTSIDE* fltk. Once some device has matured > it can be included in fltk/src/some_device subtree, the main candidate > would be of course the cairo backend when finished. The early > abstraction adoption would also help to keep binary ABI compatibility > for longer period even after large rendering implementation changes and > introduction of new devices. I'm not so sure about that. I suspect that the addition of devices could need some redesign or additional parameters or (virtual) methods in the base class(es). This would break the ABI. > The biggest problem is abstraction of the image classes - there are > three core ones: Fl_RGB_Image, Fl_Pixmap and Fl_Bitmap, the rest does > not override draw() methods. The abstraction can be relatively cleanly > solved by removing platform-dependent code from the draw() functions of > these classes and instead use of "global" fl_draw_image(), > fl_draw_pixmap()(which need to be slightly changed) and fl_draw_bitmap() > (not yet implemented) and which would just redirected the output to a > device offscreen for caching and fast sub-sequent rendering (the classes > more-less already do that in this way, in the case of postscript/pdf > such a cache can be uses as a dictionary entry to reduce data stream - > but that depends entirely on how particular device wish to implement > it). But as mentioned above the particular image function abstraction > can be done at any time later until binary compatibility freeze is required. Oh yes, I saw the changes in the caching etc. (in the mentioned 1.1.4 patch), but didn't really understand what this is good for. I'll have to take a deeper look into the (fltk 1.2) code... > PS: If you want to use some postscript code from the Fl_Device patch, > use the code from 1.2 tree as it is more recent and known bugs were > fixed there. Also win32 printing device is improved okay, 1.2 would be the base to look and maybe copy from. > but do not use any > automatic diff patching against 1.2 tree as 1.2 also include some > complete rubbish styling code (sorry, my fault). I don't think that this would be possible anyway, because too much has changed since. > I would also simplify > the inheritance structure of Fl_Device classes compared to the original > Fl_Device patch. I can remember that you proposed a structure/hierarchy in your 2009 posting. And I have some ideas, but I need to learn more about the existing 1.2 code and compare. Thanks for all your valuable tips. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
