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

Stephan Assmus <superstippi@xxxxxx> wrote:
> Axel Dörfler wrote (2007-11-05, 11:58:46 [+0100]):
> > That cannot be the reason the way FrameResized() is called.
[...]
> 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.

Ah, okay, now I understand you - it's important to retrieve all of 
those changes, and not just get the current one. I actually didn't 
notice that when implementing the asynchronous version.

> 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.

> Which means using Bounds() in FrameResized() is unreliable. Should we 
> duplicate this in Haiku (by using the values from the message), or 
> should 
> we make FrameResized() synchronous again, provided that the actual 
> fix for 
> #301 was not to call FrameResized() as long as the view as not 
> attached to 
> a window? I would be in favour of the later, since I am sure a lot of 
> code 
> calls Bounds() in FrameResized() (just look at our repo...) and it is 
> quite 
> convenient to be able to rely on that.

I'm not sure if calling FrameResized() synchronously has any other bad 
side effects, but it sounds like the best option. At least I would 
think that bug #301 indeed only relies on having a window already.
Just make sure to test it with various apps before committing it :-)

Bye,
   Axel.

Other related posts: