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. "MacArthur, Ian (SELEX GALILEO, UK)" Oct 28, 2011  
 
> 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.

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.



SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
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'.