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