> manolo gouy wrote:
> > Albrecht: I don't understand your concern here.
> > Could you explain it please?
>
> Okay, first of all: this has nothing to do with your coding, there
> was certainly no offense intended.  I apologize if it could be
> interpreted in such a way.
>
> It's just precaution because there were only about two days testing
> period and probably only three people who tested.
>
> The difference between the old and the current code is the Fl_Device
> abstraction layer.  The old code was an extension with only minimal
> changes in the FLTK core, but the new device abstraction layer is
> going deeply into the FLTK core, and *maybe* there are side effects
> that we didn't see, e.g. performance degradation by virtual methods,
> but also potential unknown side effects.
>
> ....
> Albrecht

Thanks so much Albrecht for your detailed reply I completely share.
I understand that one can imagine performance degradation by virtual
methods, and that a complete testing is necessary. I'm the first
not to want our work become a dead project.

My conclusion has been that without device abstraction we would
never have had Linux printing, and without Linux printing we would
never have had FLTK printing support. So that's why I added device
abstraction.

So developers clearly grasp what changes are involved in the core
of FLTK-1.3, I present them here conceptually but accurately:

Before
-in file src/fl_draw.cxx
void fl_rect(x,y,w,h) {
  drawing statements with platform-specific #ifdef's
}

After
-in file FL/fl_draw.H:
inline fl_rect(x,y,w,h) { fl_device->draw(x,y,w,h); };

-in file src/fl_draw.cxx:
void Fl_Device::rect(x,y,w,h) {
  EXACTLY the same drawing statements as before
}

-in files src/Fl_win32.cxx, Fl_cocoa.mm and Fl_x.cxx:
FL_EXPORT Fl_Display fl_display_device;
Fl_Device *fl_device = (Fl_Device*)&fl_display_device;


For each fl_XXX() function of the FLTK graphics API (that does more
than calling other fl_XXX() functions), the two changes shown above,
(1) inlining the fl_XXX() function and (2) changing the first line of
what was before fl_XXX() function, are done. No other change is
involved for graphics to screen operations.

For MSWin and Mac printing, a few statements were added
within Fl_Device::XXX() functions. On MSWin, because GDI is not
completely device independant: most operations are in logical units,
but some (clipping in particular) are in device units. On Mac,
because antialiasing is best applied more often than for screen output.

For X11 printing (that's now really PostScript file output), ALL
Fl_Device::XXX() functions were written from scratch, by Roman, to
produce PostScript code. Image to PostScript functions have
not yet been transferred from 1.2 to 1.3-Fl_Printer.

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to