> 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... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
