[interfacekit] Re: async BView::FrameResized()

Axel Dörfler wrote (2007-11-05, 11:58:46 [+0100]):
> Stephan Assmus <superstippi@xxxxxx> wrote:
> > The simple question: Why is FrameResized() not called directly from 
> > BView::_ResizeBy()? Only to have a valid Window()->CurrentMessage()? Or 
> > were there other reasons? How could we make sure that using Bounds() in 
> > FrameResized() would always equal the width/height argument? Or should 
> > assuming that be considered a bug in the client application (provided 
> > the 
> > same problem exists on R5)?
> 
> Looking at our SVN history reveals an answer for that one: 
> http://svn.berlios.de/viewcvs/haiku?rev=17009&view=rev 
> http://dev.haiku-os.org/ticket/301
> 
> I guess one could work around that differently, but actually, I don't see 
> why FrameResized() needs to be called with width/height arguments that 
> actually differ from Bounds(). In fact, this is how we call 
> FrameResized() in BView when a B_VIEW_RESIZED message arrives:
>     FrameResized(fBounds.Width(), fBounds.Height());
> 
> IOW:
> > Obviously, if the width/height arguments are 
> > not equal to the Bounds() width/height, then it will invalidate the 
> > wrong 
> > parts of the view. This is actually what happens, and I think what I 
> > described is the reason for why it happens on Haiku.
> 
> That cannot be the reason the way FrameResized() is called.

No, that's exactly the reason. But what you said means that using the 
width/height arguments wouldn't help either, because they are the same as 
Bounds() width/height by design. If we actually used the width/height from 
the message, than it could even work if the client code ignored Bounds() in 
FrameResized().

To explain again what happens: Imagine BBox being resized 3 times quickly 
in succession. It should invalidate three different regions. If 
FrameResized() is now called asynchronously, Bounds() might return the same 
thing each time FrameResized() is called, but for three different regions 
to be invalidated, FrameResized() should be called with the width/height of 
the time when the resize happened, not the now current values.

I will test how R5 behaves (if it's possible to get different values for 
current Bounds() and what is passed to FrameResized()) and then all we need 
to change is use the values from the message and consider using Bounds() in 
FrameResized() a bug. Although that would be quite non-intuitive.

Best regards,
-Stephan

Other related posts: