快速响应的交互式图表/图形：SVG、画布、其他？

Question

我正在尝试选择正确的技术来更新一个项目，该项目基本上在可缩放、可平移的图形中呈现数千个点。当前的实现，使用Prothvis，性能不佳。在这里查看：

http://www.planethunters.org/classify

完全缩小后大约有2000个点。尝试使用底部的控制柄放大一点，然后拖动它进行平移。你会发现，如果你没有一台速度非常快的计算机，那么在一个内核上，CPU的使用率可能会达到100%。焦点区域的每一个变化都需要对protovis进行重新绘制，这非常缓慢，而且绘制的点数越多，效果就越差。

我想对界面进行一些更新，并改变底层的可视化技术，使其在动画和交互方面更具响应性。从下面的文章中，似乎可以在另一个基于SVG的库或基于画布的库之间进行选择：

http://www.sitepoint.com/how-to-choose-between-canvas-and-svg/

d3.js源于Protovis，基于SVG，应该更擅长渲染动画。然而，我对它有多好以及它的性能上限持怀疑态度。出于这个原因，我还考虑使用基于画布的库（如KineticJS）进行更全面的检修。然而，在我深入使用这种或那种方法之前，我想听听用这么多数据做过类似web应用程序的人的意见，并听听他们的意见。

最重要的是性能，其次是易于添加其他交互功能和对动画进行编程。一次可能不会超过2000点，每个点上都有那些小误差条。放大、缩小和平移需要流畅。如果最新的SVG库在这方面表现不错，那么使用d3的便利性可能会超过KineticJS等的增加设置。但是如果使用画布有巨大的性能优势，尤其是对于计算机速度较慢的人来说，那么我肯定更愿意走那条路。

《纽约时报》制作的应用程序示例，使用SVG，但动画仍然流畅：http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html . 如果我可以获得这种性能，而不必编写自己的画布绘制代码，我可能会选择SVG。

我注意到一些用户使用了d3的混合版本。js操作与画布渲染相结合。然而，我在网上找不到太多关于这篇文章的文档，也无法联系到这篇文章的专栏。如果有人有过这种DOM到画布（演示、代码）实现的经验，我也想听听您的意见。这似乎是一个很好的混合体，既可以操作数据，又可以对如何渲染数据进行自定义控制（从而提高性能），但我想知道，如果必须将所有内容加载到DOM中，是否仍会降低速度。

我知道有一些现有的问题与这个问题相似，但没有一个问题是完全相同的。谢谢你的帮助。

后续：我最终使用的实现位于https://github.com/zooniverse/LightCurves

Answer 1

我最近开发了一个近乎实时的仪表板（每5秒刷新一次），并选择使用使用画布渲染的图表。

我们尝试了Highcharts（基于SVG的JavaScript图表库）和CanvasJS（基于画布的JavaScript图表库）。虽然Highcharts是一个很棒的图表API，提供了更多的功能，但我们决定使用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图表声称使用SVG或Canvas，但尚未查看它们。

当性能非常关键时，应该考虑画布。SVG具有灵活性。并不是说画布框架不灵活，而是需要为画布框架分配更多的工作才能获得与svg框架相同的功能。

Answer 2

我认为，在您的案例中，canvas和svg之间的决定不像是“骑马”或“驾驶”保时捷之间的决定。对我来说，这更像是关于汽车颜色的决定。

让我解释一下：假设，基于框架的操作

• 画一颗星，
• 添加星号和
• 删除星形

采用线性时间。所以，如果您对框架的决定是好的，那么它会快一点，否则会慢一点。

如果你继续假设框架的速度很快，那么很明显，缺乏性能是由大量的星星造成的，处理它们是任何框架都不能为你做的，至少我不知道这一点。

我想说的是，这个问题的基础引出了计算几何的一个基本问题，即：范围搜索和计算机图形学的另一个问题：细节层次。

为了解决性能问题，您需要实现一个好的预处理器，该处理器能够非常快速地找到要显示的星星，并且可能能够根据缩放比例将靠近的星星聚集在一起。唯一能让你的视野保持生动和快速的就是尽可能少地画星星。

正如您所说，最重要的是性能，而不是我倾向于使用canvas，因为它在没有DOM操作的情况下工作。它还提供了使用webGL的机会，大大提高了图形性能。

顺便说一句：你检查了paper.js?它使用画布，但模拟矢量图形。

PS：在这本书中，您可以找到关于web上的图形、canvas、SVG和DHTML的技术、优缺点的非常详细的讨论。

Answer 3

幸运的是，画2000个圆是一个很容易测试的例子。下面是四种可能的实现，Canvas和SVG各两种：

• 画布几何缩放
• 画布语义缩放
• SVG几何缩放
• SVG语义缩放

这些示例使用D3的缩放行为来实现缩放和平移。除了圆是在画布还是SVG中渲染外，另一个主要区别是使用几何缩放还是语义缩放。

几何缩放意味着对整个视口应用单个变换：放大时，圆变大。语义对比度缩放意味着分别对每个圆应用变换：放大时，圆的大小保持不变，但它们分散开来。飞机入口。org目前使用语义缩放，但考虑其他情况可能会有用。

几何缩放简化了实现：应用一次平移和缩放，然后重新渲染所有圆。SVG实现特别简单，只更新一个“transform”属性。这两个几何缩放示例的性能都非常好。对于语义缩放，您会注意到D3比Protovis快得多。这是因为它对每个缩放事件所做的工作要少得多。（Protovis版本必须重新计算所有元素上的所有属性。）基于画布的语义缩放比SVG要灵活一些，但SVG语义缩放仍然感觉灵敏。

然而，没有灵丹妙药可以提高性能，而且这四种可能的方法并没有涵盖所有可能性。例如，您可以结合几何和语义缩放，使用几何方法进行平移（更新“转换”属性），并且在缩放时只重新绘制单个圆圈。您甚至可以将这些技术中的一种或多种与CSS3转换相结合，以添加一些硬件加速（如在分层边缘捆绑示例中），尽管这可能难以实现并且可能会引入视觉工件。

尽管如此，我个人的偏好是尽可能多地保留在SVG中，当渲染成为瓶颈时，仅将画布用于“内部循环”。SVG为开发提供了许多便利，如CSS、数据连接和元素检查器，因此从画布开始进行优化往往为时过早。将画布与SVG相结合，就像您链接的Facebook IPO可视化一样，是一种灵活的方法，可以保留大多数这些便利，同时仍能保持最佳性能。我在立体主义中也使用了这种技巧。js，其中时间序列可视化的特例非常适合位图缓存。

正如这些示例所示，您可以将D3与画布一起使用，即使D3的某些部分是特定于SVG的。请参见此力定向图和此碰撞检测示例。