> > On 13 Mar 2012, at 18:14, Manolo Gouy wrote: > > > About adding a cairo-based drawing capability to FLTK 1.3 > >=20 > > The class hierarchy defines class Fl_Graphics_Driver with mostly > > virtual member methods implemented in its platform-specific subclasses > > Fl_Xlib_Graphics_Driver, Fl_Quartz_Graphics_Driver, etc... > >=20 > > > (by the way, this legacy mixup has been recently removed from FLTK = > 3.0) > >=20 > > But this does not prevent to define a new > > Fl_Cairo_Graphics_Driver class that implements ALL virtual methods > > of Fl_Graphics_Driver, because the virtual mechanism > > will never run Fl_Graphics_Driver::fl_rect() if you use an instance > > of the Fl_Cairo_Graphics_Driver. This is already operational > > with the Fl_PostScript_Graphics_Driver that does its job > > without any problem. > > > So... As a worked example, are we saying that starting from the = > Postscript driver is possibly the best bet for guidance in implementing = > a new driver, or...?
My suggestion would be to start from whatever extant driver is closest in philosophy to the cairo driver, either PostScript or Quartz. Besides implementing all virtual functions of the Fl_Graphics_Driver class, there are a few display-only operations to be considered, fl_scroll() that scrolls an on-screen rectangle and redraws only the newly exposed portions, and fl_read_image() that reads from an on-screen window, for example. How would these interact with cairo rendering? _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
