Mantis - tweak
Viewing Issue Advanced Details
1301 Any minor always 06-02-05 18:31 06-04-05 05:06
not fixable  
0001301: obscure not needed full redraw in mixed clipped layout
In a layout where some players are clipped and some are not,
the following can happen:


if you move one of the scrollpane players, the player "problem" gets a not needed full draw. If problems clipping is set to true, only the moved player
gets redrawn.


w := CPlayer new.
w costume := CWindow.
w hResizing: #rigid; vResizing: #rigid.
w layout := CSimpleLayout new.
problem := CPlayer new.
problem hResizing: #spaceFill; vResizing: #spaceFill.
problem layout := CTableLayout new.
problem layout listDirection: #topToBottom.
"problem clipping := true."

w add: problem.

bar := CPlayer new.
problem add: bar.
bar layout := CTableLayout new.
bar layout listDirection: #leftToRight.
bar add: CRectanglePlayer new.
bar add: CRectanglePlayer new.
bar add: CRectanglePlayer new.

s := CScrollPane new.
problem add: s.
s add: CRectanglePlayer new.
s add: CRectanglePlayer new.

w open.

06-03-05 02:50   
I don't understand the problem description. In particular the sentence "if you move one of the scrollpane players, the player "problem" gets a not needed full draw" is unclear. I cannot "move" the scrollpane players simply because they are contained in a table layout and therfore not freely movable. And I'm not sure what a "not needed full draw" would be. Playing around with the example (both with and without clipping) does not seem to make any difference. Perhaps a screenshot might help?
06-03-05 11:10   
"if you move one of the scrollpane players"
means in code something like this:

tomove := CRectanglePlayer new.
s add: tomove.
tomove position := tomove position + (10@0).

'the player "problem" gets a not needed full draw' means:
if you enable debugShowDamage, you see that there is is a full draw in the
extent of the player "problem" if problems clipping is false.

if clipping is true, only the player "tomove" is redrawn.

The issue is, there is no visual difference here if clipping is set to true or false. But an there is an enormous performance difference. If this isn't a bug, then it has to be documentented, so one can add the "clipping := true" lines in ones own code. I had this problem and and it costed me serveral hours to detect it.
06-04-05 05:06   
This is a known issue with layouts. In your example, what happens is that you have conflicting constraints: One constraint for "problem" is that it should have the size of its container (#spaceFill), however the contents *in* problem is wider than the container allows. And "problem" is not allowed to clip which here translates to: it cannot get any smaller than its contents.

The result is a set of unsatisfiable constraints and rather than giving you an endless recursion we try to find "some" solution to the problem and finding that solution can be inefficient (as you have seen). Setting either problem (or bar for that matter) to clipping, or making the window wide enough to satisfy the constraints will have the desired effect (e.g., avoid extra invalidations). And the statement that there's no visual difference is only true since both window and content pane clip - try to set them to not clipping to see that there is indeed a very noticable difference in what happens).

BTW, I'm hoping that we can put this layout mess to rest pretty soon (this is why I'm closing the bug) since Philipp is just working on some really nice stuff for layouts.