On 13.03.2012 12:49, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> Of course, it looks amazing. Especially for the Control Sequence polygons >> in Non-DAW and the Ambisonics panners in Non-Mixer, as they're quite curvy. >> It is indeed slightly slower (but I expected that because it's still going >> through FLTK's double buffer).
You (the OP, J. Liles) could try to use single buffered windows for speed comparison, even if it flickers... > Cool. Screenshots at all? > (Before/after, just to emphasise the advantages etc. would be really neat...) Yes, please! I'd like to see the differences to learn how much this would improve our FLTK feeling. >> However, when I dig into the FLTK code to look for a place to install this >> permanently, I find a bizarre mess of #if defined(USE_X11) type junk. What >> is the point of having different classes that inherit from Fl_Graphics_Driver >> if you're just going to implement everything in the base class using >> conditional compilation? > > History. > Most of the code, in particular a lot of the ifdefs, predate the graphics > driver abstraction, and so the code is still working its way to becoming > clean. > It's a work in progress. But it is getting there... > >> Would it not be infinitely more sane to have >> Fl_Xlib_Graphics_Driver.cxx and Fl_Quartz_Graphics_Driver.cxx (and now >> Fl_Cairo_Graphics_Driver.cxx) instead of trying to blend them all into a >> single class? > > Yes. See above. That would be the way to go, but there is still more to do. As it is done now, there is not a perfect hierarchy of classes and implementation of virtual methods, as it should be in the final stage. What Manolo did was enough to make the device abstraction layer support the printing devices we needed to do Win-GDI and PostScript printing. Another technical aspect would be to separate all device-specific files in different directories, as it is done in FLTK 2 (IIRC). The main problem we have with these changes is that it is difficult for us (devs) to change all IDE files (Win VC++, Mac Xcode) and other build systems (e.g. CMake), since we don't have some older dev tools (VC++) etc. There is work in progress, however, for FLTK 3 to make this easier... >> You can still conditionally compile whole files, you know, and >> it is far easier to read and maintain that way. I wanted to just make a copy >> of Xlib graphics driver and start swapping in the cairo calls, but, due to >> the >> strangeness of the Fl_Graphics_Device hierarchy, it doesn't look like it's >> going >> to be that easy. > > I think it may actually be less weird than it looks; that is, I think the > historic file hierarchy obscures things and makes it look less organised than > it really is... > For new work, having a driver-layer per-file must surely be a cleaner > separation. > >> I'm open to suggestions, especially if you guys ever want to >> merge this into the mainline. Looks like my nice clean 1 hour hack is going >> to >> turn into several days of reorganizing the hierarchy. That would probably also mean adding and changing virtual methods so that we can't do this in the 1.3.x updates because of ABI changes. Now that we have so much work done in FLTK 3, it is not clear how to proceed: go to a new 1.4 version (having to do parallel work in 3.0), or wait until we see that FLTK 3 will be able to fly and do it only there? When will that be? Do we need FLTK 2 compatibility, or should we drop that idea and go ahead with FLTK 1 compatibility only? ... > I think you need, if possible, to liaise with the people doing the graphics > driver abstraction, get them to outline how it is supposed to work, and see > if that makes sense for you. I think there were docs posted about this, but, > erm, I can't find them now... I wasn't really paying attention. > Manolo knows how it works, so he might be best? Hmm, yes, Manolo probably knows best what the current structures are, and it seems that he's working on adding a PDF device class, but this will probably only work with ABI breaking changes as well. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
