'Re: Reflow and invalidation'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-layout
Subject:    Re: Reflow and invalidation
From:       Boris Zbarsky <bzbarsky () mit ! edu>
Date:       2003-11-15 5:04:30
[Download RAW message or body]

Robert O'Callahan wrote:
> This is wretchedly unclear and it's about time we documented it :-).

I wasn't asking just because I was bored... ;)

>> 1)  Frame is resized (eg "width" attr of image changed)
> 
> The parent frame is responsible for invalidating the difference between 
> the old and new rects.

OK.  We could use a nice function on nsRect to compute the disjunction 
of two rects (A \union B) - (A \intersect B) for use here, no?

Come to think of it, in my example the resized frame would need to 
invalidate all of itself (since it would be rescaling the image)... Your 
example of <body> growing during pageload is better.

> If the resized frame needs to repaint more of its 
> area (e.g., if it has borders) then it is responsible for invalidating 
> that. See ns[HTML]ContainerFrame::CheckInvalidateSizeChange.

OK.  We may want to optimize that a bit at some point, maybe.... (we may 
not need to repaint the whole rect just to move the bottom/right borders 
about...)

>> 2)  Frame is repositioned (eg "align" attr of <legend> changed)
> 
> The parent frame is responsible for invalidating the union of the old 
> and new areas.

OK.  Makes sense.

>> 3)  Both
> 
> As #2.

OK.

> I'm not sure what else is actually done in the code.

Lol.  I don't think we care, since I doubt it's too consistent.

> It's quite likely that the above policy isn't always followed.

You think?  ;)

> It is important that when a frame grows we don't invalidate its 
> whole area

Agreed.

> but maybe cause extra redundant calls to Invalidate

How expensive is Invalidate()?  It just coalesces rects or appends a 
rect to a region, right?  It may be worth paying the price of extra 
Invalidate() calls for clarity if Invalidate() is very fast...

> (because the parent can often coalesce invalidates and/or just invalidate everything when that 
> is inevitable).

And there is that.

> Once dbaron has chimed in we should write this down somewhere, probably 
> in the reflow document.

I'd vote we document at least something about this on the nsIFrame 
methods that resize/reposition the frame.  If nothing else, add a 
pointer to the appropriate reflow document section there.

-Boris
_______________________________________________
mozilla-layout mailing list
mozilla-layout@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-layout
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic