
|
[haiku-appserver]
||
[Date Prev]
[10-2005 Date Index]
[Date Next]
||
[Thread Prev]
[10-2005 Thread Index]
[Thread Next]
[haiku-appserver] Re: Scrolling (was Re: breakthrough)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 24 Oct 2005 12:40:46 +0200 CEST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On Sun, 23 Oct 2005, Adi Oanca wrote:
> > Ingo Weinhold wrote:
> [...]
> >> BTW, since the number of messages in the looper port is actually
> > > no
> >> indicator of how busy the window thread is at the moment (only how
> > > busy it
> >> was since it last transferred the messages from the port to its
> > > message
> >> queue), it might be a good idea to let the app server know the
> > > number of
> >> messages in the queue (e.g. through shared memory), so that the
> >> server-side queue could also be used when the port is not full but
> > > there
> >> are too many messages in the client side message queue already.
> > I don't know... I don't think there's a strong reason for
> > this...
> > The messages in the port queue are fetched after any message is
> > processed, and the MessageQueue object does its job very good. If
> > processing
> > a message takes so long that the port queue gets filled up, that's
> > an example
> > of bad programming - user should use a specialised thread.
> Sure, but the case I'm referring to is that the window manages to
> process
> the individual messages fast enough so that the looper port doesn't
> fill
> up, but slower than they arrive. E.g. if there are already a few
> hundred
> messages in the queue, it might be a good idea, if the app server
> doesn't
> send B_MOUSE_MOVED messages at the full rate anymore.
How about sending a message to the app_server in this case? Something
like "argl, please slow down!"? That would be more expensive than
shared memory, but also a lot easier to implement, and since it's
assumed that the window is still somehow responsive, sounds like a good
solution to me.
Bye,
Axel.
|

|