On 12 Mar 2012, at 21:11, Greg Ercolano wrote:

>       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.

Yes - I think that's the intent, and the low-level abstraction in fltk-1.3 
should make this feasible; well, less infeasible, anyway...

As noted elsewhere, this is pretty much what Cocoa/Quartz does for us, so all 
OSX rendering is anti-aliased out of the box.

>       This, as opposed to improving the overall look of FLTK by
>       redesigning the widgets to use Cairo so as to make skinning
>       widgets possible.

Yup, I think that's another (though related) issue.

> 
>       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.

Yes, the current Cairo mechanism in 1.3, is kinda like an Fl_Gl_Window 
capability, for Cairo, not a full rendering layer.


> 
>       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.

Yes, that's basically the plan, though at present it only calls the "display" 
driver (whatever that is on a given platform) or the "printer". So an X11 build 
gets Xlib or Postscript, generally. We'd want to add Cairo and EGL and Wayland 
and...

(Going further, I guess we could have alternate "display" contexts in a given 
app, some Cairo, some Xlib, for example, if we really wanted, though what that 
would be good for... Might be useful to leverage Cairo's PDF backend, to get 
output from stuff... Well, that's mainly what I use Cairo for, anyway!)





_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to