We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
假设做了海量的类似表格的页面。其中CELL 再滚动时候如何优化性能。 实测发现5000个RECT 在首次渲染 及 滚动时候卡滞。 但是 文档中也没有标记 有什么方法实现与viewPort的碰撞检测方案。
The text was updated successfully, but these errors were encountered:
在处理大量 DisplayObject 时,尤其是在滚动时遇到性能问题,可以考虑以下几种优化策略:
DisplayObject
虚拟滚动:只渲染当前视口内可见的元素,而不是所有元素。随着用户滚动,动态加载和卸载元素。这可以显著减少渲染的 DOM 元素数量。
使用 requestAnimationFrame:在滚动时使用 requestAnimationFrame 来优化动画和渲染。这样可以确保在浏览器的刷新频率下进行渲染,减少不必要的重绘。
requestAnimationFrame
批量更新:将多次 DOM 操作合并为一次操作,以减少重排和重绘的次数。
图层化:将频繁变化的元素提升为独立的图层,这样可以减少重绘的范围。
碰撞检测:虽然文档中没有提到具体的实现方法,但可以考虑使用四叉树或网格等数据结构来优化碰撞检测的效率。
如果需要更具体的实现建议或代码示例,可以查看相关的开源项目或社区讨论,或者在 antvis/G 的 GitHub 仓库中搜索相关的 issue 和 pull request。
如果有进一步的问题或需要更详细的帮助,请随时告知!
Sorry, something went wrong.
类似虚拟滚动列表的技术,需要在应用侧实现。
另外,在目前的实现中应尽可能避免频繁的销毁并重新实例化元素,可以尝试重用元素实例去不断的更新属性。这是因为目前 G 的实现中事件传播机制有缺陷,即便是元素实例量级比较小的情况下,频繁的销毁和实例化也会导致在一帧中事件处理要比渲染的时长更长。
No branches or pull requests
假设做了海量的类似表格的页面。其中CELL 再滚动时候如何优化性能。
实测发现5000个RECT 在首次渲染 及 滚动时候卡滞。
但是 文档中也没有标记 有什么方法实现与viewPort的碰撞检测方案。
The text was updated successfully, but these errors were encountered: