g 中是否考虑加入分层（layer）

[doolewind]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

What problem does this feature solve?

一个图形应用一般都会由好几部分构成，而会经常变化，或者变化比较复杂的又可能只是其中一部分，图形较少的时候没有任何问题，如果图形比较多，就需要分层来避免不必要的重绘以免引起卡顿。

我没有在文档中找到类似功能，g 引擎是否有未在文档显示的API实际上拥有layer类似的功能吗？

What does the proposed API look like?

zrender相关API： https://ecomfe.github.io/zrender-doc/public/api.html#configlayerzlevel-config

[dengfuping]

• G 4.0 的性能优化机制有四种，分别是 局部渲染、异步渲染、自动渲染和渲染裁剪，其优化思路与 zrender 不太一样。分层渲染 是一种比较典型而且容易实现的性能优化机制，但需要上层手动去做(设置 zlevel)。相对而言，局部渲染 的实现难度更大，但优化潜力也更大，且上层不需要感知，G 这一层会自动做掉。这种优化思路本质上是通过更少的数学计算成本来降低重绘成本，而数学上的优化是无穷尽的，因此 局部渲染 的潜力非常巨大。
• 有兴趣可以看下 G 4.0 的性能优化设计文档 https://www.yuque.com/antv/ou292n/pcgt5g

[doolewind]

@dengfuping 感谢你的解答。

我还有一个问题，我看了一下代码实现，g 应该是基于「脏矩形」进行局部渲染的，大部分情况下是很好的，但是这个计算量在一些情况下会非常大，比如不规则图形的频繁改动或者联动。

请问 g 是如何解决某些情况下相关算法计算量过大的情况？

[dengfuping]

• 这种情况是存在的，尤其是对于复杂的 path 来说。但如果计算成本小于全局重绘的成本，那么还是可以接受的，即使在这些边界情况下的性能提升可能不会特别大。目前的思路可能是尽量减少不必要的计算步骤和次数，尽量保证计算成本最低。
• 比如这个性能优化的 PR #490，涉及到的性能优化手段有: 在 Group 层对 canvasBBox 加缓存(之前只在 Shape 层有缓存)、通过 pre-check 对真正要重绘的 element 进行标记、父子元素同时更新只将最顶层的父元素加入刷新队列等。
• 后续计划的性能优化手段有:
  • 结合 canvasBBox 进行拾取性能优化，最小化遍历次数；
  • 实现分片渲染，动态调节渲染帧率，交互会更流畅。