手势双指移动时的性能优化

[PYLXU]

功能描述 | Description

我认为或许可行的方案：

1. 可以学习Squid（安卓App）等产品，对于距离当前区域较远的区域不再保留在页面上，而是存储低像素的图片，当移动到该区域时显示低像素图片，延时一段时间后显示墨迹
2. 对于墨迹超出宽度/高度较多时间，可以考虑“关联页”，自动创建一个新页面或不外显的创建页面，当区域过大可能引起卡顿时将这些数据转为可视区域内可见的图片（例如可以做一个虚线作为页面分隔符，虚线以右的笔迹会转为下一页，当页面中心切换时自动转换可视区）
3. 或许加入漫游功能 白板加入“漫游”按钮 #174 ，不实时识别手势或许能够提高移动性能（？

需求动机 | Motivation

墨迹过多后移动页面出现卡顿的现象

期望设计 | Expected Design

No response

其他补充信息 | Additional Info

No response

[CJKmkp]

无法复现卡顿情况，仅有些许延迟

[douxiba]

功能描述 | Description

我认为或许可行的方案：

1. 可以学习Squid（安卓App）等产品，对于距离当前区域较远的区域不再保留在页面上，而是存储低像素的图片，当移动到该区域时显示低像素图片，延时一段时间后显示墨迹
2. 对于墨迹超出宽度/高度较多时间，可以考虑“关联页”，自动创建一个新页面或不外显的创建页面，当区域过大可能引起卡顿时将这些数据转为可视区域内可见的图片（例如可以做一个虚线作为页面分隔符，虚线以右的笔迹会转为下一页，当页面中心切换时自动转换可视区）
3. 或许加入漫游功能 白板加入“漫游”按钮 #174 ，不实时识别手势或许能够提高移动性能（？

需求动机 | Motivation

墨迹过多后移动页面出现卡顿的现象

期望设计 | Expected Design

No response

其他补充信息 | Additional Info

No response

1. 没用，这个东西不需要缓存成Bitmap，而且如果你真要缓存，那必须得用RenderBitmapTarget将Visual渲染成位图，不仅占空间，效果还不明显。WPF本身就是看不见的就不渲染的。如果要做BitmapCache的话，实现是个问题，虽然可以自己实现InkCanvas控件解决，但是iccce还是别想了。（而且用BitmapCache真的高效吗？在屏幕上变更时需要在矢量和位图之间来回踢皮球，我觉得并不高效）
2. 可以考虑在空闲时候缓存部分屏幕外的墨迹到本地以减少内存占用。至于转图片，还是1所述，没有意义。
3. 手势识别只是灵敏度过高，性能还是没问题的。有轻微的性能影响完全可以忽略不计。这里其实也可以优化一下触摸手势的灵敏度，建议加入阈值和死区，或是直接在漫游模式下引入叠加的DirectManipulation解决问题。

至于卡顿的原因，究其根本是因为Ink Canvas系列的墨迹漫游全部是对墨迹Stroke内的StylusPoint做Matrix数学运算来实现Transform的，这就导致每次移动墨迹都会进行大量StylusPoint的计算、重绘制和渲染。

要想真正解决这个问题，首先是先把能上Freezable的给上了来，其次就是全部用RenderTransform。墨迹全部堆到一个地方，相对位移用RenderTransform，页面漫游也用Visual的RenderTransform，这样只需要重新渲染即可，不再需要重新绘制，性能当然更高。

也可以在空闲的时候对墨迹进行Flatten操作，因为矢量渲染也很耗费显卡性能。不过需要显示只有非常长的大片重叠大面积墨迹才能应用。

---

而且要知道，连希沃的Cvte.Paint.Inks都没解决大量墨迹同时渲染导致卡顿的问题，我们还是不要妄想在WPF中能够完美解决了。除非你走D2D的DirectComposition或者WinRT的Composition UI，这些都高性能，但是很多东西需要自己造。而且还有Airspace问题。

[douxiba]

总而言之可以修复，但是现在修不了

[PYLXU]

无法复现卡顿情况，仅有些许延迟

我好像确实提了一堆没用的想法
我发现只有在页面墨迹多的时候才会出现移动卡顿
确实不太好优化，或许可以直接关闭这个议题（？

[PYLXU]

老师在使用时漫游明显比鸿合白板软件卡顿太多了，再加上还需要用双指移动，就想来问问有没有搞头（x

[douxiba]

老师在使用时漫游明显比鸿合白板软件卡顿太多了，再加上还需要用双指移动，就想来问问有没有搞头（x

有搞头，但需要重构。这个问题不需要单独解决，重构InkCanvas控件过后自然会解决。现在这一套就是屎山