Greetings, I'm the author of several large free-software projects which utilize FLTK (http://non.tuxfamily.org). When I started these projects way back in 2007, I decided to use FLTK because part of the reason I needed the programs was because I was unable to find any hardware sufficiently fast to render existing GTK applications in the same problem space. At that time, GTK2 was unbearably slow on configurations not supporting XRender. Also, I have no interest in platform libraries and didn't want to bring in all of the dependencies associated with GTK. Having started Non-Sequencer using Motiff, FLTK was a definite step up in usability. However, I soon learned that in order to do just about anything (e.g. automatic layout, sensible widget behavior, drag/drop) with FLTK, I would have to do it from scratch. I didn't mind this, however, because my applications worked exactly the way I wanted and were blindingly fast and started instantly, very much out performing any of the other programs in same the problem space (which all used GTK/QT).
However, even then the resistance of users to FLTK was palpable. The general perception being that FLTK was ugly (lacking themes, antialiased lines, and alpha blending) and hard to use (fixed sized windows or windows that don't resize well and layouts that don't flow automatically). I was able to overcome most of this by application of pure effort in implementing my own custom controls, overriding the default boxtypes, and applying a less eye-searing color scheme. 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. Of course the fact that it may be fixed already does little good, because FLTK 1.3.0 is already widely distributed and is not likely to be updated in distributions' archives for several years yet... So I had to swtich to static linking against a custom patched version of FLTK. 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. And still, nothing has been done to enhance the user experience on X11. OS X users get anti-aliased lines and alpha blending. Windows users get alpha blending at least. But X11 gets none of this--it gets crippling performance problems. I'm interested in perhaps patching FLTK to use XRender for all drawing to bring it up to a more modern standard, but that does nothing to solve the double buffering problem, whatever it may be. From what I can tell, GTK/cairo don't even use XDBE and instead use XCB-SHM, which, honestly, seems perfectly reasonable and probably accounts for the reason that GTK performance has outstripped FLTK in recent years. All of this brings me to the issue of Cairo. GTK uses cairo exclusively now. People who have tried Cairo in FLTK and found it to be slow have been bypassing the doublebuffering and SHM extensions that are what enables Cairo to render GTK applications with good performance. If FLTK were to use Cairo for all of its drawing on X11, I think that the situation would be improved in the following ways: 1. It would look better. 2. It would be more capable 3. It would perform better 4. The problem of dealing with bugs and developments in X11 would be shifted out of FLTK 5. Developers could resume their habit of only giving attention to OS X and Windows platforms without leaving us lowly X11 users hanging out to dry after investing years of time in FLTK. 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. 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. Believe me, I know. I hear it all the time from users who question my sanity--users who cannot be convinced that it is only slow on their systems and I can't reproduce the problem on mine.This is quite a turn of events from when GTK was hundreds of times slower than FLTK and the ugliness seemed justifiable... I don't know if this situation is as disappointing to all of you as it is to me, but I'm certainly beginning to question the wisdom of investing 5 years of my life in FLTK. Help me turn this situation around. Help me modernize FLTK on X11. I feel like people have secret patches to do all rendering in Cairo that they gave up on because it was slow the first time they tried it and I just can't find them. I'm reluctant to put a lot of effort into XRender support when FLTK will still be unusably slow on many systems due to the doublebuffering problem, and *always* slower than GTK due to not taking advantage of shared memory. This is not a huge technical problem, but it is something that definitely needs attention. 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. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
