makes sense. its the timing and not the number of events.
On Thu, Dec 12, 2013 at 11:25 PM, Antoine Martin <[email protected]>wrote: > On 13/12/13 11:59, ... wrote: > > https://www.xpra.org/trac/ticket/137 > > > > I was just looking through this. I like the tablet idea, well for > tablets. > > I'd love to see games through xpra on a linux tablet, if not android. > The android client needs work and doesn't even handle keyboard input at > all, and mouse only just. > > As for actual mouse movements, I don't know squat about how things are > > working, but the thought I had on seeing this is having python or cython > The choice of language wouldn't really matter. > > doing interpolation between mouse positions on the server (client?) side, > > simulating the acceleration that the game is going to try and do anyway. > > > > Has that been considered / is it workable? > I don't think that this would improve things, only make things more > complicated. > We already have the mouse events that the application should be > receiving, those are the events we receive client side. No need to > interpolate anything. > Adding the option to send all mouse events (and not just the last one we > find time to send as we do at present) would be trivial to implement, > the extra bandwidth costs should be immaterial if you are targeting gaming. > The difficulty is in delivering the events to the remote application > with the same exact gap between them as they had when we received them. > This could probably be solved by artificially delaying *all* mouse > events by a delay (based on the network jitter) that restores the > original gap. > > Antoine > _______________________________________________ > shifter-users mailing list > [email protected] > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
