On 11 Mar 2012, at 20:06, J. Liles wrote: > 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.
Meh. And I can't grok git; do you know what svn revision that equates to at all? > 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. Did you spot any common factor at all? Do they all have "similar" graphics h/w (e.g. all intel? ALl ATI/AMD, Nvidia? Anything? I had a bad time with some Via graphics on one machine, but that affected all GUI equally...) or... similar distro? Or...? > 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. Though X11 bitrot, and the functional spread, and general API clutter, is (more or less) why Wayland got kicked into life... > 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. Which is exactly why the abstraction of the rendering code in fltk-1.3 is important, and why, if someone had the time and ability, it should be very feasible now to make fltk use EGL or Cairo for the low-level rendering... (And also why, I suspect, you see a load of commits that just look like variables being renamed!) I agree with you that "fixing" the lower-level is a win for all users, so that, as with Cocoa, every app "instantly" gets free anti-aliasing. But the back-end needs to be configurable, so that apps still run on hosts (or servers anyway) where the "preferred" back-end is not available... -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
