On 06/10/11 11:54, Evan Laforge wrote:
>> ..we probably need to go into some details in the "Drawing Things in FLTK"
>> section about how the coordinate space works for widgets vs. windows.
>
> Speaking of which, why is it that way in the first place?
I think it was mainly a speed issue, to allow widget drawing
code to go as fast as possible, and not have to worry about
one widget relative to another in large hierarchies.
FLTK is basically exposing the way drawing is actually
handled by the base libraries (xlib, win32) where all coords
are relative to the corner of the window.
I believe Bill cited this in his original documentation
which may not have survived to the to the current incarnation
of the docs, not sure. (Perhaps he went into these details
in old forum postings, not sure)
It was, IIRC, a design issue where he wanted drawing
to go as fast as possible (the F in FLTK), and not get
caught up in having to convert offsets for all x/y coords
used in drawing, and having to maintain these offsets
throughout the widget hierarchy when widgets are moved around.
I recall he even went into details that the widget would
know best about how to handle drawing details esp. in the
context of resizes, or during resizing/repositioning of
widgets.
I believe he also cited the devil was in the details
of maintaining these offsets in the context of widget
resizing, and could cause the internals of the widget lib
to take long excursions to maintain these values.
All of this was apparently avoided by simply not trying
to do all that work by default, and simply expose the
way the window manager presented the coordinate space
to all widgets, where their own logic could determine
the best way to handle drawing.
Bill can probably put it in better words, as I recall
it was something he did very much on purpose in the
original FLTK design. Hope I'm remembering this correctly..!
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
