加入“非实时渲染”以解决频繁绘制 canvas 带来的卡顿问题

[liudding]

No description provided.

[liudding]

非实时渲染

在 canvas 下面放置一个 <image/>, 当移动图片、放大缩小图片时，不对 canvas 执行绘制，而是更新 <image/> 的位置和大小。当最后点击触发 getCropperImage 时，再执行绘制 canvas。

本次 pr 欠缺之处：

• 在 weCropper 中引用了 pageContext。造成循环引用
• 在 weCropper 中更新 page 页面，且使用了固定变量 cropperOpt
• mpvue-cropper 未修改。

[dlhandsome]

能否有办法避免在库中setData呢，因为这样处理的话，和外部cropperOpt耦合了，能否做成外部的拓展模块，因为imgLeft、imgTop等属性是可以通过实例拿到的

[liudding]

如果要在外部 page 中更新 UI 的话，这就可以解决 cropperOpt 耦合的问题了。可以在 __oneTouchMove 和 __twoTouchMove 中放置两个钩子函数，比如 onTouchMove， 然后开发者在自己的 page 中调用钩子函数来 setData。

这样会有个问题： <image/> 要由开发者去处理。以及 <image/> 是放在 template 里，还是开发者自己写在 page 里。

更好的方式应该是：开发者在使用 we-cropper 时，只需指定参数和监听事件，其他裁切相关的具体逻辑都无需过问。

如果将 cropperOpt 定义为固定的接口参数，那在 we-cropper 里 setData应该就不是问题。只需在裁切成功、失败以及取消之后，再 we-cropper.pageContext = null 来解决循环引用导致的内存泄漏问题。

如果以小程序的 component 组件 来实现 we-cropper，是不是会更合适

[dlhandsome]

这里我的考虑是，we-cropper理念还是设计成一个库，最终可以运行在各个平台（框架）上，尽可能脱离宿主上下文环境，目前we-cropper缺乏一套可靠的插件拓展机制，这个是一个必须解决的首要问题。

[aheadcn]

更新你的代码以后，跑不起来呀，cropperImageSrc imageTop 这些属性都是获不到值，例子，应该是1.2版本的吧，

[JE-lee]

非实时渲染是否可以考虑对selft.updateCanvas() 做节流处理,这样子是否就可以不依赖于外部page 的image 标签?
而且通过 <image styel="top:{{imageTop}}"> 这种方式来操作节点，貌似也有很大的性能问题。我之前有个案例做拖拽的，就试过再touchmove 中操作style 的top,left，真的很卡。

做个trace 对比如何？

[BoleLee]

[小心翼翼地]问下这个准备发新版本了吗？

[aheadcn]

文件特别大，选择原图，移动和裁切都非常卡