Scroll latency testing? about walt HOT 5 OPEN

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.

from walt.

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.

from walt.

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

from walt.

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.

from walt.

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.

from walt.