Skip to content
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

Open
ecsfang opened this issue Sep 9, 2016 · 5 comments
Open

Scroll latency testing? #49

ecsfang opened this issue Sep 9, 2016 · 5 comments

Comments

@ecsfang
Copy link

ecsfang commented Sep 9, 2016

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.

@kamrik
Copy link
Contributor

kamrik commented Sep 9, 2016

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.

@ecsfang
Copy link
Author

ecsfang commented Sep 10, 2016

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.
Even if the drag latency is low, there might be delays in the touch driver detecting scroll movement, so there might be a long delay until scrolling starts, but after scroll detection the dragging is fast enough.
This is also a very important kpi for the user, to get a quick start of the scrolling. Unwanted delays are easily noticeable and has a negative impact on the look and feel of the UI.

@kamrik
Copy link
Contributor

kamrik commented Sep 12, 2016

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 :)

@kamrik
Copy link
Contributor

kamrik commented Sep 12, 2016

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.

@ecsfang
Copy link
Author

ecsfang commented Sep 13, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants