[haiku-appserver] Re: input issues

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 15 Apr 2005 16:02:49 +0200 CEST

"Stephan Assmus" <superstippi@xxxxxx> wrote:
> > > > Instead, we should follow the path R5 has chosen, and use a 
> > > > direct handshake for updating the mouse cursor position only 
> > > > (note, the view transfer messages are still done over the 
> > > > standard 
> > > > message path, only the *visual* position update is not, since 
> > > > that's all that matters for perception).
> >     I don't understand...
> >     Are you talking about redirecting B_MOUSE_DOWN messages to 
> > the client BLooper? I remember sawing something like this in R5.
> > (redirect_input_server() was called, I think)
> I think :-) what he is saying is that there should be two paths for 
> updating the mouse position. One is a direct link from the 
> input_server 
> to the app_server, and it updates the cursor on screen without taking 
> any app_server client communication into account. The second path is 

Exactly, that's what I meant.

> the messaging from the app_server to the client. (I don't think this 
> would need to be a duplicate stream from input_server -> app_server.) 
> But this would be done asynchronously from the updating of the mouse 
> position on screen.

I would have a duplicate stream as this would simplify the 
communication. The cursor positioning only cares about the actual 
position, while the app_server also wants to know when the update was 
sent, etc.
Of course, if you don't need to overwrite the same buffer over and over 
again, you wouldn't need to update it atomically, and then you could 
put more info in it as well. But then you could have a slow mouse 
cursor again, as it would have to catch up with the messages on load, 
instead of just moving directly to the current position. Dunno what 
looks better, though.

> mouse position path:
> input_server -> app_server -> on screen cursor (immediate update)
>                            -> forward message to client 
> (asynchronoulsy
>                                   and independent of the above)
> 
> Did I get it right, Axel? That being said, I have not looked closely 
> at 
> how it is currently done in app_server, but I would trust Axels 
> observation that the client forwarding is done synchronoulsy to the 
> on-
> screen update.

With the disclaimer above about the forwarding, that's right :)
You would also need to create a new BPortLink message from the cursor 
information, and since it doesn't have any short-cuts for intra team 
communication (unlike BMessages), it wouldn't be cheaper than just 
sending the message from the input_server.

Bye,
   Axel.


Other related posts: