On Mon, Mar 12, 2012 at 2:11 PM, Greg Ercolano <[email protected]> wrote:
> On 03/12/12 10:28, J. Liles wrote: > > Just to keep this discussion sane: the only thing that widgets > > containing only straight lines have to benefit from Cario is alpha > > blending. > > > And any changes to style would be better made in the > > boxtypes... It's more important that fl_line, arc, curve, polygon and > > friends use Cairo so that diagonal lines and curves don't show > > aliasing. > > I see, so it sounds like what you're looking for > is to have a Cairo enabled build of FLTK > that redirects calls like fl_line() > to use Cairo instead of xlib. > > The benefit being any lines drawn by FLTK widgets that might > use e.g. diagonal lines or draw rounded edges can benefit > looks-wise via anti-aliasing. > > This, as opposed to improving the overall look of FLTK by > redesigning the widgets to use Cairo so as to make skinning > widgets possible. > > It's my understanding (I might be wrong) that currently a Cairo > enabled build of FLTK really only enables a few things so that > *Cairo* drawing calls can draw into FLTK windows, but not much > else has been done to make use of Cairo internally by FLTK. > > I think the graphics driver abstraction added to fltk 1.3.x > might help make this easy. > > From what I can tell, calls like fl_arc() end up calling > fl_graphics_driver->arc(x,y,w,h,a1,a2) to do the actual work, > which I think Fl_Device actually handles. > > So this can probably be done by changing Fl_Device.H > so that the current 'Xlib' section has some extra ifdefs > for Cairo so that if Cairo is enabled, fl_xxx calls > invoke cairo functions instead of Xlib. > OK. Since nobody else has tried it, apparently, and clearly I have nothing better to do (yeah, right...) I went ahead and implemented all the fl_draw functions as defined, but using cairo to draw intead of xlib. Currently, the switch is made by including a header file with macros that translate e.g. fl_line to fl_cairo_line. Of course, it looks amazing. Especially for the Control Sequence polygons in Non-DAW and the Ambisonics panners in Non-Mixer, as they're quite curvy. It is indeed slightly slower (but I expected that because it's still going through FLTK's double buffer). However, when I dig into the FLTK code to look for a place to install this permanently, I find a bizarre mess of #if defined(USE_X11) type junk. What is the point of having different classes that inherit from Fl_Graphics_Driver if you're just going to implement everything in the base class using conditional compilation? Would it not be infinitely more sane to have Fl_Xlib_Graphics_Driver.cxx and Fl_Quartz_Graphics_Driver.cxx (and now Fl_Cairo_Graphics_Driver.cxx) instead of trying to blend them all into a single class? You can still conditionally compile whole files, you know, and it is far easier to read and maintain that way. I wanted to just make a copy of Xlib graphics driver and start swapping in the cairo calls, but, due to the strangeness of the Fl_Graphics_Device hierarchy, it doesn't look like it's going to be that easy. I'm open to suggestions, especially if you guys ever want to merge this into the mainline. Looks like my nice clean 1 hour hack is going to turn into several days of reorganizing the hierarchy.
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
