On 04/02/2011 19:39, Manolo Gouy wrote:
>
> I'm not in favor of making all those stubs public, at least for 1.3,
Fair enought , that can be ddone later without breaking source api (not sure
about binary, that might depend on compiler).
> - The Fl_Graphics_Driver API is smaller than the series of
> fl_xxx() functions that deal with drawing, colors and fonts:
> o some functions are independent from any graphics driver
> (e.g., fl_color_average())
Right, this is not drawing function, it is stateless and should never be a part
of graphics driver.
It does not mean that if just some function is in <FL/fl_draw.h> header it
should be automatically a part of the graphics driver.
> o others don't draw anything (e.g., fl_color(void))
But it DEPENDS on the state of the drawing device. Having setting function
color(Fl_Color c) a part of the driver but NOT getting one (with void) is
inconsistent. If you have one a part of the driver then the other should be
included too and each driver should remember its own current colour (having
color_
internal member or equivalent). Otherwise there would be no reason to have the
first one in the driver either, the driver could just query a global variable
and
adjust colour (if necessary) before each drawing. The same applies to font, ...
> o others are deliberately out of this API (e.g., fl_width()
> because fonts are a very complex business already with the
> display, so we don't multiply that to yet other devices)
A future TODO ? Many devices (like cairo) could return correct values for the
font used and would take great advantage if such function would exist.
For now I would suggest to inclclude overridable width() function to the
graphics driver with the base implementation using this hack with screen font
(but for
size and face of particular device). Once such overridable function exists, the
new devices can reimplement it (if they wish so) and take advantage of their
font system and better measurement.
> - Switch between surfaces (and associated graphics drivers)
> is very simple and fast:
> my_surface->set_current()
Sure, but one can image a situation with creating a document not in one go but
incrementally, or in another thread (if the document creation takes time and you
want to keep interface responsive). In such a case simple screen redraw would
mess up the state of the driver - even if you do not use screen at all.
Another example would be eg custom canvas widget like
class My_Canvas: public Fl_Widget{
public:
void draw(Fl_Graphic_Driver * d, int x, int y, int w, int h) const {
...
d->draw(...); // not yet possible, not public
...
}
protected:
void draw(){ // wrapper for normal screen drawing function
draw(fl_graphic_driver, x(), y(), w(), h());
}
};
with possibility to use the functions concurrently (see const declaration in
the first draw() function).
Just my 2c.
Of course all this can wait after 1.3.
Roman
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
