Dragging feels sluggish with the Asynchronous Touch Driver.

[stc1988]

Build environment: macOS
Moddable SDK version: 8.2.3
Target device: M5StackCoreS3

Steps to Reproduce

1. Build and install the example app examples/piu/drag using this build command: mcconfig -d -m ...

Images

Asynchronous Touch Driver.

async.mov

This is from when I switched to the synchronous touch driver ($(MODDABLE)/modules/drivers/sensors/ft6206/manifest.json)

sync.mov

[phoddie]

Asynchronous operation inherently has some latency compared to synchronous operation. The advantage is that it doesn't block other operations. It is a tradeoff. Do you have an idea of how to optimize this?

[phoddie]

Three ideas for you to try:

1. Reduce the number of SMBus transactions to retrieve the touch points. We can drop that from 2 to 1 by combining them. This reduces cross task trips and minimizes I²C overhead.
2. Poll more aggressively (M5Stack Core S3 doesn't have an interrupt to notify of touch events). It is currently 17 ms. You can drop to 3 ms, for example, when touch is being tracked. Note that I recommend keeping a relatively high number (50 ms) for the initial touch.
3. Adjust the touch controller configuration - the configure() method can help with that, though perhaps you will need to extend it.

(1) and (2) are implemented in this Gist to get you started.

[stc1988]

Thanks for confirming. I tried your implementation, but it doesn’t seem to have improved the issue.

I don’t think the title’s use of “sluggish” is quite accurate. On my end, onTouchEnd tends to fire during dragging, making it look like the drag is being interrupted.

[phoddie]

Thanks for confirming. I tried your implementation, but it doesn’t seem to have improved the issue.

It is a start. Not a solution.

On my end, onTouchEnd tends to fire during dragging, making it look like the drag is being interrupted.

That seems like something else.

[stc1988]

I’m checking the logs from your implementation, and it seems that even while dragging, the number of touches read from the register can sometimes be 0. In that case, sample returns [], which results in onTouchEnd being triggered.

[phoddie]

I noticed that touch on the M5Stack Core S3 requires me to push harder than most devices. But that is the same across the sync or async driver. But the behavior is similar to you seeing no touch reports. Maybe there is a configuration that needs to be different for this device?

[stc1988]

It does work relatively well when I consciously press harder while dragging. Maybe the async processing made the issue more noticeable.

I’ll check how the settings are configured in the official M5Stack implementation.

[stc1988]

I haven’t found the exact configuration values yet, but I suspect the touch sensitivity threshold may need to be adjusted, as the M5Stack CoreS3 uses an IPS display protected by high-strength glass.

[stc1988]

In ft6206_async, configure() can be called before the asynchronous chip check completes. In that case, the options are stored in io.configure and applied later. However, the current merge order uses {...options, ...io.configure}, so the default values in io.configure override the user-provided options. As a result, calling configure({ threshold: 20 }) immediately after construction does not override the default threshold of 128.

The merge order should probably be {...io.configure, ...options} so that later configure() calls override the defaults.　I confirmed this issue resolved by changing the merge order.

IMG_3886.mov

[phoddie]

That makes sense. So, it kind of was a misconfiguration, but not in the way I imagined. I'll update the driver. Thank you for helping to track this down.

FWIW – I'm sure that (1) above is a good change. It is less over-all work and it avoids one turn through the event loop. While you may not have felt a difference, it is surely lower latency and lower overhead.

[stc1988]

This issue has fixed in 8.3.0. Thank you.