On 03/20/12 13:53, Jerome M. Berger wrote:
Speaking of 3.0, is it already usable? With *relative* widget
coordinates? (the latter is the main reason I use 2.0 instead of 1.x).
Unless you want to help with 3.0 dev or testing,
I would suggest against using it until it has
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).
Cool. Screenshots at all?
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,
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.
Another nice thing I expect this will allow is alpha for the various
drawing primitives that accept colors. For instance, I
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
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
I'd just like to mention I've also been discouraged by the ifdef
thicket in the OS specific files. But Manolo was always so fast at
fixing any