-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scroll latency testing? #49
Comments
The drag / scroll latency test already works on Android. It uses the laser so that we can measure the scroll input latency separately, without the graphics output latency added. Look for the up/down arrows icon in the app and then press start in there. The laser can be any laser pointer. |
Yes, but that is for continuous dragging, I was thinking of the scroll start latency, i.e. the time from finger touchdown until actual start of the scrolling. This can be measured with e.g. a high speed camera, detecting first touch until scrolling begins, but you should be able to do that with the Walt as well, i.e the time from accelerometer down event until the screen changes. |
Ah, got it now. I think, for scroll start latency we can use almost the same procedure as for tap, but instead of timing the arrrival of the ACTION_DOWN event, we could time the arrival of the first ACTION_MOVE event. Should also be doable without using the photodiode. Would probably require fairly minor tweaking in the Android app Java code. Not sure if there what additional latency can be caused higher level event filtering, say some buffering of ACTION_MOVE events in software before it decides that the user's intention was actually to scroll - most likely this behaviour is tuned per device model. The procedure you describe with the photodiode would require some more work, but also doable. I won't have the time to add it in the near future, but pull requests are always welcome :) |
Talked with some people here about this, we did measure the scroll start latency at some point but most of it was added deliberately by software to distinguish between intended scroll and unintended movement during tap. |
Ok. I thought most of the time was spent in the touch driver, so this would give us a measurement on the system and driver (in a normal app, afaik, no scroll detection is done, that is handled by the os/ui). I could then compare changes to the touch driver, and could detect degrades (this I have been able to do with the tap latency). It could also be that one device have different screen vendors and different touch drivers and this would be one way to compare these. |
Would it be possible to add scroll latency testing also for Android phones and tablets?
I.e. when the app detects a scroll event, we could flip the screen from/to black/white.
So, by detecting the tap down event (as with tap latency), and then with the screen sensor detect the screen update, we should be able to quantify the scroll (start) latency as well.
The text was updated successfully, but these errors were encountered: