快速响应的交互式图表/图形: SVG、Canvas、其他？
我正在尝试选择正确的技术用于更新项目，该项目基本上在可缩放、可平移的图形中呈现数千个点。目前的实现，使用Protovis，表现不佳。点击这里查看：
http://www.planethunters.org/classify
当完全缩小时，大约有2000个点。尝试使用底部的手柄来放大一点，然后拖动它来平移。你会发现它是非常不稳定的，除非你有一台非常快的计算机，否则你的CPU使用率可能会在一个核心上达到100%。每次对焦点区域的更改都需要重新绘制到protovis，这非常慢，绘制的点越多，情况就越糟糕。
我想对界面进行一些更新，并改变底层的可视化技术，以使动画和交互更具响应性。从下面的文章中，似乎可以在另一个基于SVG的库和一个基于画布的库之间做出选择：
http://www.sitepoint.com/how-to-choose-between-canvas-and-svg/
从Protovis发展而来的d3.js是基于SVG的，并且是supposed to be better at rendering animations。然而，我怀疑它到底有多好，它的性能上限是多少。出于这个原因，我还在考虑使用像KineticJS这样的基于画布的库进行更彻底的改造。然而，在我使用这样或那样的方法之前，我想听听有人用这么多数据做过类似的web应用程序，并听取他们的意见。
最重要的是性能，其次是易于添加其他交互功能和编程动画。一次可能不会超过2000个点，每个点上都有那些小误差条。的放大、缩小和平移需要流畅。如果最新的SVG库在这方面做得不错，那么使用d3的易用性可能会超过KineticJS等增加的设置。但如果使用画布有巨大的性能优势，特别是对于计算机速度较慢的人，那么我肯定更喜欢这样做。
由使用SVG的NYTimes制作的应用程序示例：http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html。如果我可以获得这样的性能，而不必编写自己的画布绘制代码，我可能会选择SVG。
我注意到一些用户使用了d3.js manipulation combined with canvas rendering的混合体。然而，我在网上找不到太多关于这方面的文档，也没有联系到那篇文章的评论。如果任何人有做这种DOM- to -Canvas (demo，code)实现的经验，我也希望能听到你的意见。它似乎是能够操作数据和对如何呈现数据(以及性能)进行自定义控制的一个很好的混合体，但我想知道，是否必须将所有内容都加载到DOM中仍然会减慢速度。
我知道有一些现有的问题与这个问题类似，但没有一个问题是完全相同的。谢谢你的帮助。
Follow- up ：我最终使用的实现是https://github.com/zooniverse/LightCurves
回答 5
Stack Overflow用户
发布于 2012-09-09 07:59:17
幸运的是，绘制2000个圆是一个非常容易测试的示例。所以这里有四个可能的实现，Canvas和SVG各两个：
这些示例使用D3的zoom behavior来实现缩放和平移。除了圆是在Canvas中呈现还是在SVG中呈现之外，另一个主要区别是您是否使用几何缩放或语义缩放。
几何缩放意味着将单个变换应用于整个视口:放大时，圆会变大。相比之下，语义缩放意味着您将变换单独应用于每个圆:当您放大时，圆保持相同的大小，但它们展开。Planethunters.org目前使用语义缩放，但考虑其他情况可能会很有用。
几何缩放简化了实现:只需应用一次平移和缩放，然后所有圆都将重新渲染。SVG实现特别简单，只需更新一个"transform“属性。这两个几何缩放示例的性能感觉已经足够了。对于语义缩放，你会注意到D3比Protovis快很多。这是因为它为每个缩放事件做的工作要少得多。( Protovis版本必须重新计算所有元素的所有属性。)基于画布的语义缩放比SVG更快一些，但SVG语义缩放仍然具有响应性。
例如，你可以结合使用几何和语义缩放，使用几何方法进行平移(更新“”属性)，并且在缩放时只重画单个圆。您甚至可以将这些技术中的一种或多种与CSS3转换结合起来，以添加一些硬件加速(就像在hierarchical edge bundling example中一样)，尽管这可能很难实现，并且可能会引入可视工件。
尽管如此，我个人的偏好是尽可能多地将保留在SVG中，当渲染是的瓶颈时，只将Canvas用于“内部循环”。SVG具有如此多的开发便利性--例如CSS、数据连接和元素检查器--以至于从Canvas开始进行优化往往为时过早。将Canvas与SVG结合起来，就像您链接的Facebook IPO可视化一样，是一种灵活的方法，可以保留大多数这些便利，同时仍能勉强保持最佳性能。我还在Cubism.js中使用了这种技术，在这种情况下，时间序列可视化非常适合于位图缓存。
如这些示例所示，您可以将D3与Canvas一起使用，即使D3的某些部分是特定于SVG的。另请参阅此force-directed graph和此collision detection example。
Stack Overflow用户
发布于 2012-09-08 19:45:38
我认为在你的案例中，在canvas和svg之间的决定不像是在骑着马或驾驶保时捷之间的决定。对我来说，这更像是关于汽车颜色的决定。
让我来解释一下:假设基于框架的操作
- 绘制一颗星，
- 添加一颗星，
- 删除一颗星
用线性时间。所以，如果你对框架的决定是好的，它就会快一点，否则就会慢一点。
如果你继续假设框架只是快速的，那么很明显，缺乏性能是由于大量的星形和处理它们是没有框架可以为你做的，至少我不知道这一点。
我想说的是，这个问题的基础导致了一个基本的计算几何问题，即：range searching和另一个计算机图形学：level of detail。
为了解决你的性能问题，你需要实现一个很好的预处理器，它能够非常快速地找到要显示的星星，并且可能能够根据缩放比例将接近的星星聚集在一起。唯一能让你的视野保持鲜活和快速的事情就是尽可能的减少要画的星星的数量。
正如您所说的，最重要的是性能，而不是我倾向于使用canvas，因为它不需要DOM操作。它还提供了使用webGL的机会，这将大大提高图形性能。
顺便说一句:你检查过paper.js了吗？它使用画布，但模拟矢量图形。
PS：In this Book你可以找到一个非常详细的讨论，关于网络图形，画布，SVG和DHTML的技术，利弊。
Stack Overflow用户
发布于 2014-08-07 23:47:20
我最近开发了一个近乎实时的仪表板(每5秒刷新一次)，并选择使用使用canvas呈现的图表。
我们尝试了Highcharts(基于SVG的JavaScript制图库)和CanvasJS(基于画布的JavaScript制图库)。虽然Highcharts是一个很棒的图表应用编程接口，并且提供了更多的功能，但我们还是决定使用CanvasJS。
我们需要为每个图表显示至少15分钟的数据(可以选择最多两个小时的范围)。
因此，在15分钟内:900点(每秒数据点)x2(线条和条形图) x4图表= 7200点。
使用chrome profiler，使用CanvasJS时，内存从未超过30MB，而使用Highcharts时，内存使用量超过600MB。
同样，在刷新时间为5秒的情况下，CanvasJS渲染的响应速度比Highcharts更快。
我们使用一个定时器(setInterval 5秒)进行了4次REST API调用，从连接到Elasticsearch的后端服务器拉取数据。作为数据更新的每个图表都由JQuery.post()接收。
这就是说，对于离线报告，我会使用Highcharts，因为它的API更灵活。
还有Zing charts，它声称使用SVG或Canvas，但还没有看过它们。
当性能非常关键时，应该考虑Canvas。SVG实现了灵活性。并不是说canvas框架不灵活，而是canvas框架需要做更多的工作才能获得与svg框架相同的功能。
https://stackoverflow.com/questions/12310024
复制相似问题