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

  • From: Adi Oanca <adioanca@xxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sun, 23 Oct 2005 20:49:04 +0300

Hi Ingo,

Ingo Weinhold wrote:
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
this aspect in mid. If an _UPDATE_ message is dropped, we are in big

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.

That's exactly what I was thinking about.
IMO too, you can't always deliver all messages to your target, but you have to make sure, the most important ones do arrive.

In the case of update this can be much easier, in that we won't simply exclude the region to be update(from the "general" one), but do that only if sending the _UPDATE_ message succeeded.

BTW, I'm pretty sure I know why BWindow's port gets filled up when using the new code and a B_VIEW_MOVED/RESIZED message per view. It's because in ServerWindow object we lock the RootLayer object for every operation that we need to do. Getting the view's coordinates following a BView::Bounds(), does not require RootLayer locking.
I will take care of this problem shortly by grouping messages that need locking(drawing ones includes) and those who don't.

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.

That's a good idea. Maybe picasso thread could be used for that too.

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.

Thanks for your input Ingo!

bye, Adi.

Other related posts: