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

[Adi Oanca <adioanca@xxxxxxxxx>]

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

	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.