On 03/10/12 00:23, J. Liles wrote:
> Not much has changed since then, except that FLTK seems to continue to
> diverge into different development paths (although, from looking at
> the diffs between the different branches, I actually see little change
> other than the incomprehensible renaming of symbols) and introduce
> annoying new bugs on the X11 platform.
>
> Once such bug, introduced in FLTK 1.3.0, but perhaps already fixed in
> the development versions, caused any application drawing into an
> Fl_Overlay_Window's overlay plane to have to redraw the entire
> underlay buffer every time the overlay was damaged, completely
> defeating the purpose of Fl_Overlay_Window and introducing a many
> thousand fold performance degradation.
Please open an STR for this, and if possible, provide
an example program and describe the hardware combo
that shows the issue.
> Now I'm getting reports from users about truly unbearable slowness (2
> seconds to redraw the window) for all FLTK applications using
> Fl_Double_Window (which is pretty much all FLTK applications),
> regardless of FLTK version and whether or not FLTK was built with
> --enable-xdbe.
Ditto -- I don't think I've heard of this one,
and I use linux as my main workstation, so I'd have
thought I'd encountered it.
> 6. Maybe users would see an antialiased line or two and stop spewing
> so much vitriol at me about how awful FLTK is and how stupid I must be
> for not just using GTK like everyone else.
Yes, I get this too.
> As it stands right now, the opinion of the general public on Linux/X11
> is that FLTK is antiquated crap, just like Xt or Motiff, and any
> program using it must be both a PITA to use *and* unbearably slow.
The "unbearably slow" is a mystery to me.
Can you point us at an example?
Open an STR, please, so we can fix this.
It sure sounds like it's an issue with specific hardware
or software combo somehow.. something that it might be
possible to get with any toolkit.
> And I'm sure that there are people here who know more about
> Cairo and the subsystems and mechanisms it employs than I do. Why not
> take a break from renaming symbols for a while and think hard about
> where FLTK is going? Cairo seems like the best insurance policy
> available against complete obsolescence and rejection.
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.
Old Fl_Widget would still be accessible, even with cairo enabled,
so people building 1.x apps with cairo would be unaffected.
There'd just be some extra widgets called Fl2_Xxx that they wouldn't
use. But new experimental code could use the new Fl2_Xxx widgets,
and perhaps eventually this could become a stable API that piggybacks
with FLTK 1.x.
This, as opposed to creating a whole new and separate widget library
like happened with FLTK2, which became an unmanageable and redundant
code fork.
This way we still keep the old FLTK stuff, and slowly build
up a new interface around the old engine.
Just a thought.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
