Originally posted by indepe
View Post
This is the problem minuscule alterations in latency do come noticeable to those doing speed runs and other things.
There is a catch here. Yes you would think the time stamp on input events will fix things. Problem lots of game engines and some common 3d sculpting applications work from the applications own internal time clock so complete disregarding input event timestamps. So speed from input device to application comes critical and preferable constant.
Do note you said if the ping as not been responded to due to some delay stop sending messages. So timing the ping is not your only factor here.
Think if you are running right on edge with time slices that the event buffer is almost full before before you application gets to process and catch up. The ping without responded pong equals that you have stop filling the buffer while it still has space. All those delayed messages. So the effect of the ping/pong to latency is worse than just the cost to send the ping.
Yes the fact you said how long to takes to send a ping as that justifed it says you have not been testing this to edge. Testing to edge you do need software uinput device todo it dependable.
Yes how fast can I push this tests with how many events per second being processed. I did code up a horrible test program. Check the event buffer if not 90% full it would sleep as in scheduler as in use wait(). Only when 90% full would it process the event buffer with all the event cleared. A program stalls out under the gnome ping/pong solution.
Then you do a test case where you can add custom stall amounts. Then you start find when you start hitting the failure in pong in time input latency goes up with gnome at that point.
Mostly from what I have seen indepe you have been testing the case you are debugging the application and your bring the application to complete stop then run out of buffer. You were not testing how it responds if you would be getting close to buffer full but not quite making it to buffer full.
Yes there are games that have a rendering loop and event loop that work that when they are in the event loop they process all events that are in buffer then switch to the rendering loop for X amount of time then switch back to the event loop. Different class of badly coded. Yes some of those are really bad if the event buffer was made larger as well because the game is going to start graphical stuttering because it spending too long processing events.
Originally posted by indepe
View Post
I am admit we have 2 groups of users here. In fact we have 3.
1) General users like you. You want applications not be distrupted and are willing to take latency hit that you call minuscule.
2) speed runs/some of your 3d sculpting where minor alterations in latency are going to get noticed. Yes 1ns and less counts to these users..
3) Embedded critical safety users are going do the ping and failure to pong will be application termination and restart application because the program has have a issue because it not responding so need to be replaced because it not responding.
One of the things about the open source world you can bet when there are 3 groups of uses there will be a customized solutions for all 3 with incompatibilities.
You want to say I know too little about the solutions. Problem is you are missing key big picture bit. You have not looked at what the user groups are.
indepe the 3 groups of users you cannot make all 100 percent happy with the same solution. Gnome route is more the general user route who never going to run anything that will depend on the input latency being insanely low.
The 3 group in this case we can most ignore they are not going to change from application non responding we will kill it.
Thing is I have done broader tests with automation comparing to the different use cases.
Comment