On Tue, Mar 13, 2012 at 7:16 AM, Albrecht Schlosser <[email protected]>wrote:
> 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... > Yes, Single buffered is quite fast. I think GTK is doing a lot more in the way of optimizing what is actually drawn (and perhaps doing partial updates to the front buffer), but I haven't quite figured it all out yet. > > 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. > Sure. Before and after can be found here: http://non.tuxfamily.org/cairo-test The vector knobs and the spatializer widget benefit the most. Ordinary rectangular FLTK widgets look identical, except for the possibility of alpha (I added an fl_color_alpha( Fl_Color, float alpha ) call to set color with alpha. Is there already some other mechanism for dealing with alpha as part of Fl_Color that I'm missing?) > > >> 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... > And here we begin to see why having three different branches of development without three independent teams to go along is just a hinderance to progress... I can't work with FLTK 2 or (FLTK 3?) because they senselessly change a lot of symbols and semantics and I have too large a code base to play around with porting it. I made that mistake before, porting Non-DAW to FLTK 2, only to discover that (at the time) FLTK 2 was far, far too buggy to be useful. > > >> 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 > > In that case, I should point out that liasing isn't really my style--too slow. I'll just do what makes sense to me and whoever tries to merge it can sort it out...
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
