On 24.05.2011, at 21:05, Marcel Dejean wrote: >> >> Now comes the fun part: we will create a compatibility layer for FLTK 2 as >> well. FLTK 2 has some great features that were never backported to FLTK 1. >> Well, now is the time to put them into FLTK 3! This will make FLTK as stable >> as possible while combining all the advantages of 1 and 2. >> > > Is a FLTK 2 compatibility layer really necessary? FLTK 2 never reached a > release version, so I wouldn't expect much demand for a compatibility layer.
I think yes for two reasons: 1: one major reason for this version is an "un-fork". I would love to make it easy for FLTK 2 users to join the efforts 2: is more selfish (from an FLTK 1 user view): FLTK 2 does have a bunch of nice features that we can discover, understand, and port while we do the emulation layer. > With all this comes a "code injection system" that makes it possible to >> interface FLTK 3 with any other language out there, including overriding >> existing virtual functions at run-time, like "draw()", and all the other >> FLTK features. >> > > The core application behind this being a skinning system, yes? Yes, no worries! The code injection adds one pointer per widget (but using the FLTK 2 "style" system will remove 16 bytes on the basic widgets and 32 bytes on the more complex ones, at least) and one "if" statement per virtual function. That is no biggie at all. "draw()" for example is such a function, and just drawing a single pixel on screen takes thousands of instructions, so one "if" will not make any difference (and FLTK does not make big use of virtual functions anyways). The emulation layers are almost entirely in header files. Emulation in 90% of all cases adds one single indirection (one additional read, one additional jump). Again, unless you are running on a Z80 or 6502 (or PDP11), this does not have any effect on performance. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
