On Sun, Mar 11, 2012 at 11:43 AM, Greg Ercolano <[email protected]> wrote: > > Please open an STR for this, and if possible, provide > an example program and describe the hardware combo > that shows the issue.
I'll do you one better, patch is commit 94d392c in git://git.tuxfamily.org/gitroot/non/fltk.git The issue affects all programs use Fl_Overlay_Window expecting *not* to be told to redraw the entire window every time the overlay is redrawn. I only use the overlay window in one of my programs, for the playhead in Non-DAW (and also the selection rectangle). I have no idea what the original intent of the change was, so I basically just reverted it--and I had too much trouble importing the svn history into a more usable vcs and gave up. >> 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. Believe me, I've tried my hardest to reproduce it also. I believe I may have exhausted the patience of those who do experience the problem with my constant questioning. So far, my best theory is that it has to do with offscreen pixmaps being extremely slow on some hardware and that GTK/cairo don't use them and therefore don't suffer the penalty--but I'm still trying to get someone to actually try adding the NoOffscreenPixmaps option to their xorg.conf. > > 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. Ah, but it doesn't happen with any toolkit--just FLTK! I was dumbfounded when I started hearing from users that "Oh, I wish your program didn't use FLTK. All the FLTK programs I've tried *so* slow." Frankly, I only know of one FLTK program that is slow and that's because it redraws the entire window every 100ms or so (SpiralSynthModular), not because of any fault in FLTK. But whatever this problem is, it seems to be affecting a fair percentage of people. And, that makes since when you consider the fact that the other toolkits don't use XDBE or really most of the interfaces to X that FLTK (still) uses. With GTK and QT not using them, these interfaces are just going to continue to suffer bitrot and introduce more headaches. > 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. Besides complicating life for everyone involved (now I have to change all my code to refer to the new widgets, and the FLTK lib is how big now?) I believe this kind of piecemeal approach will solve none of the problems I've described except the one of appearance. For Cairo to be fast and reliable, it must be the exclusive interface to X. It must handle the entire window surface so that it can use its accelerated access to X and the video hardware. It seems to me that just flat out replacing all direct interaction with X with Cairo calls would be the simplest, lightest, and highest performance option. *And* it would mean that existing applications don't have to be updated at all (unless they're doing something really bizarre and low level). This would be similar to the way that an FLTK program recompiled for Apple/Quartz works to just magically make it look better. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
