Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

g 中是否考虑加入分层(layer) #545

Closed
1 task done
doolewind opened this issue Jun 1, 2020 · 3 comments
Closed
1 task done

g 中是否考虑加入分层(layer) #545

doolewind opened this issue Jun 1, 2020 · 3 comments
Labels

Comments

@doolewind
Copy link

doolewind commented Jun 1, 2020

  • 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
Copy link
Member

dengfuping commented Jun 4, 2020

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

@doolewind
Copy link
Author

@dengfuping 感谢你的解答。

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

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

@dengfuping
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants