FLTK logo

Re: groupbox damaged area issue.

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: groupbox damaged area issue. Albrecht Schlosser Oct 28, 2011  
 
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.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.