
|
[haiku-appserver]
||
[Date Prev]
[10-2005 Date Index]
[Date Next]
||
[Thread Prev]
[10-2005 Thread Index]
[Thread Next]
[haiku-appserver] Re: partly paiting
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 17 Oct 2005 19:28:05 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> > If it works indeed by sending an individual message for each view
> > in R5, then
> > I must say, this is quite an overhead. I would assume that sending
> > a single
> > message is much cleaner and faster.
> You know I agree here. I haven't tested in R5, but I assume it's
> one
> message per view.
I agree as wel, for the record :).
> > Resizing a single view (for example the
> > top window view) will result in all children with B_FOLLOW_* flags
> > to be
> > moved and/or resized. On the app_server side, this is an "atomic"
> > operation,
> > but when messages are sent for each view individually, I have a bad
> > feeling
> > in my tommy, that this is a potential source of out-of-sync
> > problems on the
> > client side. We could still emulate the single current message on
> > the client
> > side and stick to the way I did it. What do you say?
> I agree sending one message only. Let's stay with this solution and
> see
> if all works OK. I just am afraid of ::DetachCurrentMessage()
> because, if this
> method is called from ::FrameMoved/Resized() the user will be dumped
> into debugger
> with a seg fault; more checking is required for "case B_VIEW_RESIZED/
> MOVED:"
I don't think you have to, as I don't think there is any point in using
this method from these methods - and if you really think otherwise, we
could still emulate the single message approach, as Stephan proposed.
I don't think it's used that often anyway in any function that deals
with BView messages.
Bye,
Axel.
|

|