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.