> On 28.10.2011 10:34, MacArthur, Ian (SELEX GALILEO, UK) wrote:
> >
> >> So you're saying the logic is that after a window area is
> >> marked as damaged (I presume that's what's happening, but
> >> don't know for sure) it is the group that determines if a
> >> child should be repainted and it only looks at its bounds
> >> (even though the position of a child is window oriented)?  Or
> >> would it be more in the lines of something like something is
> >> only scanning the first level of items in a window / group
> >> and if found to be within those bounds that it would then
> >> send that group a redraw request?  In this case it's a member
> >> of a group, and it just protrudes a little above the group bounds.
> >
> >
> > I think what happens is something like this (may be some variation
> > host-to-host but the intent goes something like this...)
> >
> > If you mark a Fl_Group for redraw, then when it is processed a clip
> > region is set that matches the bounds of the Fl_Group - the assumption
> > is that all of the groups children lie entirely within the group
> > (fast-n-light and all that) - then the drawing of the group and all it's
> > child widgets is processed.
> >
> > So, and widget that actually lies all (or partly) outside the group will
> > not be drawn (fully) due to the clip.
>
> Well put, Ian; this is possible, but it is not the default. The clipping
> is controlled by the group's clip_children(int) method, and the default
> is 0 (off). Otherwise David's label wouldn't be drawn at all outside the
> group.
>
> > No attempt is made in the default Fl_Group to compute the actual clip
> > region of the group and all its children (in case any child widgets lie
> > outside the group) as that might conceivably be expensive to do, thought
> > it would be easy enough to create a subclass of Fl_Group that did
> > compute an "overall-clip" accounting for its children and set that
> > instead in the draw method.
> >
> > In general, the idea is that if anyone creates a group that has children
> > that are physically outside of the groups natural boundary, that's a
> > special case that they have done on purpose, so they will make specific
> > provision to get the "extra" area redrawn - usually by asking the parent
> > to redraw, though a special-purpose group widget could easily be created
> > too.
>
> This is done to minimize drawing to make FLTK fast and light, as Ian
> wrote above [1]. It all works perfectly, if you keep one rule in mind:
> don't let children cross the group's boundaries, since everything
> outside the group is not guaranteed to be handled well (or as intended
> by the developer). This is particularly true for event handling: let
> a button cross the group's boundary and try to click it inside and
> outside the boundaries!
>
> I think what David describes is another, but similar problem, caused by
> the label being partly outside its group. I understand the problem so
> that another window occludes the app's window (maybe an fl_choice()
> popup window from the same app). If this happens to occlude only the
> part of the label outside the group, then this part is not redrawn
> (if it happens to occlude the group as well, then everything should
> be fine).
>
> In this case FLTK also tries to minimize drawing. As David assumed,
> FLTK gets a "damage region" (or "expose") event for some part of the
> window, when the occluding window is removed or closed. Then FLTK
> tries to find the parts that need to be drawn by checking the top
> level group (i.e. the window) for intersections with the damaged
> region (or maybe not, because this must always be true). Then it
> goes down the widget hierarchy and checks [2] all children for an
> intersection. In the described case, there will be an intersection
> with the parent group, but not with the group containing the outside
> label. Hence, the parent group will be checked and partly drawn, but
> not the group with the label, and thus the label will be "erased" by
> drawing the parent's background or any other widget lying there.
>
> *This* drawing is always done with a clip region (the damaged region
> given in the damage/expose event), and that explains what is happening.
> At least I hope so - this is all from the top off my head, so it may
> also be not completely accurate, but it should show the idea.
>
> Albrecht
>
> [1] ... and to reduce flicker
> [2] This check is done with the widget's bounding box, as Ian described
> above.

Thanks, I think I'll just move it to the parent group and let all the default processing handle it...