[haiku-appserver] Re: GetMouse()

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 20 May 2005 17:08:16 +0200 CEST

Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> > it would need to be something more like GetMouse() or even 
> > should call DoUpdate() directly.
>       I'm still not sure about this method. What I think it should do, is 
> process the _UPDATE_ request that is pending in the message queue, 
> just 
> as GetMouse() does, and above that, it should query the server if 
> there 
> still are invalid regions to be updated (regions that became invalid 
> since the server sent the last _UPDATE_ request) and if there are do, 
> get the data from the reply and do a DispatchMessage(updateMsg, this) 
> again.
>       That is a bit complicated to achieve, so I think we should stick 
> with 
> the UpdateIfNeeded() you implemented, and if problems appear, 
> consider 
> the above.

That sounds very strange to me: isn't that just a work-around for the 
awareness that the "one _UPDATE_ at a time" method is not sufficient?

> > But as I think about it: it's a bad idea that there is always only 
> > one 
> > _UPDATE_ message in the queue, as it slows down the whole thing 
> > quite a 
> > lot; the latency between to (necessary) _UPDATE_ messages is 
> > increased 
> > a lot this way and for no reason.
>       It is a bit lengthly to explain why we do that. But believe me, 
> what we 
> do it's OK. (It's optimal too. :-) )

See above. I think the optimal solution would be to do quite the 
opposite: hammering the app with contiguous _UPDATE_ messages (of 
course, the update rate could be limited), and the app must then decide 
on how to combine them for one actual drawing update.
That would be quite similar to what you propose above, with the 
difference that the data is there when it's needed, and is not queried 
for at that time (which increases latency). 
Of course, since drawing is app_server communication as well, maybe 
your version (updated as you suggested) turns out to be the same 
performance-wise, and I am not even sure what is simpler to implement 
(probably very similar, although the app_server might already have the 
logic to combine the messages).

> > How would I try FFM with our app_server? The Mouse preferences app 
> > doesn't work yet (it's one of those that let the app_server crash 
> > here) 
> > :-)
>       Later... It's not a priority ATM. :-)

Boooo! ;-)


Other related posts: