触摸屏上图片移动延迟削减方法

深藏阁楼爱情的钟 2022-07-15 00:23 308阅读 0赞

问题背景：

利用红外扫描的触摸屏会因为电视+扫描框+软件处理性能而产生延迟，在图片移动的过程中，会出现图片滞后于手指的情况。在手指移动速度很大的情况下，图片落后的距离会达到10cm左右。

问题分析：

使用高清摄像机，拍摄触摸画面，统计出延迟帧数为4帧，时间为67ms。每秒扫描框可以采集到50-120帧数据（和框性能有关），根据触摸点的个数有所不同（采集性能有限，触摸点多的情况下，单触摸点的采集频率就会降低）。所以每秒延迟的帧数并不固定，问题也就变成了如何预测接下来67ms内的移动距离。

人的手指运动，既有一定的运动规律，又充满突发性。假设用户前5帧运动了1，1，2， 3 ，5个px，接下来很有可能运动在5 – 8 之间（经验所得），也有可能运动0，1，2。

故没法用简单统一的规律预测运动轨迹。但是其中又有一些确定的规律，人不可能跳跃加速，也不可能突然减速，总是有连续的运动过程。如图一。总是先加速再减速，先运动一个加速过程，再有短暂的匀速，然后减速、短暂静止。

![SouthEast][]

图一

在平均8ms每帧的情况下，以延迟8帧作图，就会有如图二中的距离差距。从图中可以发现，在开始运动8帧之后，系统得到了相应，这时候距离差距也达到了较大值，在转换的地方，反而差距会变小，至此完成了一个小的运动周期。

![SouthEast 1][]

图二

解决方案：

在图二的情况下，最简单的想法会是把启动时间提前，这样红线就可以和标准的线完全重合了，但是仔细想想，并没办法知道用户启动时间到底会花多少帧，而且就算预测到了提前的帧数，也没办法知道前几帧应该向哪儿、运动多少，所以这种办法并没有效果。

后来我发现如果能够在移动过程中改变速度，在一个周期中，在加速的情况下多加速（下降的地方同样，也是个反向加速），因为并没有办法预测究竟该加速多少，或者当前加速的是多是少。比如说遇到一个例子，发现加速函数太小了，根本不够，还是有滞后，后来调整了系数，使得这个例子能够赶上了。接着又遇到一个，发现刚在加速的时候，位置掉头了，一下子图片产生了一个“甩尾”的情况。如图三。

![SouthEast 2][]

图三

在尝试了一些预测算法、滤波器之后，发现不可能达到很高的预测率，因为这个运动是极其Random的，如图三中的蓝线（也就是标准轨迹）。想要在加速的时候，让图片赶上手指，必定会导致来不及掉头，或者是遇到特别短促的来回平移时，会出现相反运动。

那我们只能退而求其次，尽量能够在加速的时候，给一些加速补偿，减速的时候，再尽量把加速的误差给还掉，在掉头的时候，将所有补偿去掉（抑或是弥补上，因为转向的时候突变，人眼不敏感，也不易察觉），当反向时，又是个新的运动周期。当然，加速、减速的时候都需要平滑的变化，不能突兀。图四展示了处理效果。

![SouthEast 3][]

图四

这种处理方式下，可以减少40%左右的Delay。但是虽然红线和蓝线已经贴合的很近了，红线却有的部分还是会突出蓝线之外。在表上只是突出一点，在实际软件使用的过程中，却会导致图片比手指还要提前到指定地点，这样的用户体验非常不好。所以只能退而求其次，再次降低加速的系数，使得红线永远不会超过蓝线。这样处理之后，优化的效果在10-20%之间。

加速补偿公式：C = (avgV + a) \* T \* PreValue / Le;

avgV:前5帧的平均速度/角度/大小

a：加速度

T：加速系数，根据屏幕大小动态调整

PreValue：前一帧的值

Le： 触摸屏上触摸点的个数

补偿限制公式：Limit = fabs(avgV) \* 12 / Le;

指数平滑公式：nowCal = alpha \* (PreValue + C) + (1-alpha) \* PreValue;

Alpha：0.9

[SouthEast]: /images/20220715/5b9765285db74652a8ae536d97393687.png
[SouthEast 1]: /images/20220715/a24322ac4fc5423fa7309134ed032382.png
[SouthEast 2]: /images/20220715/70bf82240ed04eda8110133284d29861.png
[SouthEast 3]: /images/20220715/293af8445ed6465daff74b28cd196c3a.png