OP described 2 separate issues: 1. slow performance of offscreen overlays, and 2. improving the look/performance of widgets using Cairo
> I agree that improving the widget's look is a good idea, > and perhaps it should start with making a new set of parallel > widgets that can easily be used or enabled in parallel with > our current releases. > > I think for the short term, perhaps adding new widgets > that parallel our old ones that get included in FLTK 1.x, > starting with Fl_Widget. > > So for instance, today one of us had a version of just Fl_Widget > that entirely uses Cairo, we could include it in the FLTK 1.x > source as e.g. Fl2_Widget. It could include skinning, styling, > all the stuff we've wanted. It could get enabled only if the > lib is built with Cairo. I would hesitate to add a whole slew of parallel widgets as such, where you would have the original Fl_* widgets and equivalent Fl_Cairo_* ones. IMHO it would be better to keep the Fl_* names as adaptors that either used conditional compilation to use the original or cairo (or whatever) internals, or used some environment variable to choose at run-time. Then people would have the same interface to FLTK and wouldn't have to change their code to use the Cairo (or whatever) alternatives. D. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
