[haiku-appserver] Re: Scrolling (was Re: breakthrough)

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sun, 23 Oct 2005 15:35:54 +0200

On 2005-10-23 at 14:06:32 [+0200], Axel Dörfler wrote:
> Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> >     But related to this I think we have another problem: Messages being
> > dropped when client's queue is full.
> >     This is a very serious problem! We didn't thought the app_server
> > with
> > this aspect in mid. If an _UPDATE_ message is dropped, we are in big
> > trouble.
> 
> This isn't a new problem, though, we share this problem with BeOS as
> well.
> There are two ways to fix this problem:
> 1) have a better delivery mechanism, like what we do with the node
> monitor for Haiku
> 2) have ports that allow for a more flexible queue - that would need to
> be solved at kernel level, and I think was one of Michael Phipps
> preferred topics :)
[...]

IMHO, trying to deliver all messages is not the best approach for the app 
server. If a window is so busy, that it can't even keep its looper port 
empty, one should definitely not try to send it all B_MOUSE_MOVED messages. 
I think on the app server side there should be a per window queue of 
outgoing messages that could not be delivered without timeout. The queue 
would store additional information that allow it to drop B_MOUSE_MOVED 
messages and compact _UPDATE_ messages.

The messages in the queues would periodically be tried to be sent, either 
by a dedicated thread doing that for all windows (similar to the 
MessageDeliverer implemented in the registrar) or maybe by the per window 
app server threads.

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.

CU, Ingo

Other related posts: