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

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

http://www.planethunters.org/classify

完全缩小时大约有2000点。尝试使用底部的手柄放大一点，然后拖动以平移。您会发现它非常不稳定，除非您有一台非常快的计算机，否则您在一个内核上的CPU使用率可能会高达100％。对焦点区域的每次更改都需要重绘到原图，这相当慢，而且绘制的点数更多时更糟。

我想对界面进行一些更新，并更改底层的可视化技术，以更好地响应动画和交互。从下面的文章来看，似乎是在另一个基于SVG的库还是一个基于画布的库之间进行选择：

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

d3.js源自Protovis，它是基于SVG的，被认为在渲染动画方面更好。但是，我对性能有多好以及性能上限有疑问。因此，我也在考虑使用基于画布的库（例如KineticJS）进行更全面的大修。但是，在我深入研究一种或另一种方法之前，我想听听有人用如此大量的数据完成了类似的Web应用程序，并征求了他们的意见。

最重要的是性能，其次是增加其他交互功能和对动画进行编程的重点。一次最多可能不会超过2000个点，每个点上都有很小的误差线。放大，缩小和平移需要平滑。如果最新的SVG库在这方面是不错的，那么使用d3的便利性可能会超过KineticJS等的增加的设置。但是，如果使用canvas具有巨大的性能优势，尤其是对于计算机速度较慢的人，那么我绝对会喜欢这样。

NYTimes使用SVG制作的应用示例，但仍可以流畅地进行动画设置：http：//www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html 。如果我可以获得这种性能，而不必编写自己的画布绘制代码，则可能会选择SVG。

我注意到有些用户使用了d3.js操纵与画布渲染相结合的方式。但是，我在网上找不到有关此文档的大量文档，也无法与该帖子的OP联系。如果任何人有执行这种DOM到画布（演示，代码）实现的经验，我也希望听到您的来信。似乎可以操纵数据并可以自定义控制如何呈现数据（因此可以提高性能），这似乎是一种很好的混合方式，但是我想知道是否必须将所有内容加载到DOM仍然会减慢速度。

我知道存在一些与此问题类似的问题，但没有一个问题完全相同。谢谢你的帮助。

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

幸运的是，绘制2000个圆是一个非常容易测试的示例。因此，这里有四个可能的实现，分别是Canvas和SVG两个：

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

这些示例使用D3的缩放行为来实现缩放和平移。除了用Canvas还是SVG绘制圆以外，另一个主要区别是使用几何缩放还是语义缩放。

几何缩放意味着您可以对整个视口应用单个变换：放大时，圆圈会变大。语义上的对比缩放意味着您将变换分别应用于每个圆：放大时，圆保持相同大小，但散开了。Planethunters.org当前使用语义缩放，但是考虑其他情况可能会很有用。

几何缩放简化了实现：您一次应用平移和缩放，然后重新绘制所有圆。SVG实现特别简单，可以更新单个“ transform”属性。这两个几何缩放示例的性能感觉都绰绰有余。对于语义缩放，您会注意到D3比Protovis快得多。这是因为对于每个缩放事件，它所做的工作要少得多。（Protovis版本必须重新计算所有元素上的所有属性。）基于Canvas的语义缩放比SVG更加活泼，但是SVG语义缩放仍然具有响应能力。

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

不过，我个人的喜好是尽可能保留SVG，并且在渲染成为瓶颈时仅将Canvas用于“内部循环”。SVG为CSS提供了许多便利，例如CSS，数据联接和元素检查器，因此从Canvas开始通常是过早的优化。如您所链接的Facebook IPO可视化中所述，将Canvas与SVG结合使用是一种灵活的方法，可以在保持最佳性能的同时保留大多数这些便利。我还在Cubism.js中使用了这种技术，在这种情况下，时序可视化的特殊情况非常适合位图缓存。

如这些示例所示，即使D3的某些部分特定于SVG，也可以将D3与Canvas一起使用。另请参阅此力导向图和此碰撞检测示例。

我认为，就您而言，画布和svg之间的决策不像“骑马”或驾驶“保时捷”之间的决策。对我来说，这更像是关于汽车颜色的决定。

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

• 画一颗星星
• 加一个星星
• 删除星星

花费线性时间。因此，如果您对框架的决定是好的，那它会快一些，否则会慢一些。

如果继续假设该框架运行很快，那么很明显的是，由于大量的恒星而导致性能下降，而处理它们却是所有框架都无法为您做的事情，至少我不知道对这个。

我要说的是，问题的根源导致了计算几何的基本问题，即：范围搜索和另一种计算机图形学：详细程度。

为了解决您的性能问题，您需要实现一个好的预处理器，该预处理器可以非常快速地找到要显示的恒星，并且也许可以根据缩放将聚集在一起的恒星聚在一起。唯一可以使您的视图生动生动的方法是，使绘制的星星数量尽可能少。

如您所述，最重要的是性能，比起我倾向于使用画布，因为它无需DOM操作即可工作。它还提供了使用webGL的机会，这大大提高了图形性能。

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

PS：在本书中，您可以找到有关网络图形，画布的技术，优缺点的详细讨论，SVG和DHTML。

我最近在一个接近实时的仪表板上工作（每5秒钟刷新一次），并选择使用通过画布渲染的图表。

我们尝试了Highcharts（基于SVG的JavaScript图表库）和CanvasJS（基于Canvas的JavaScript图表库）。尽管Highcharts是一个出色的图表API，并提供了更多功能，但我们还是决定使用CanvasJS。

每个图表我们需要显示至少15分钟的数据（可以选择最多两个小时的范围）。

因此，持续15分钟：900点（每秒数据点）x2（线和条形组合图）x4图=总计7200点。

使用CanvasJS使用chrome profiler时，内存从未超过30MB，而使用Highcharts时，内存使用量超过了600MB。

同样，刷新时间为5秒，与Highcharts相比，CanvasJS渲染的响应速度更快。

我们使用一个计时器（setInterval 5秒）进行了4次REST API调用，以从连接到Elasticsearch的后端服务器提取数据。JQuery.post（）接收作为数据更新的每个图表。

也就是说，对于脱机报告，我会选择Highcharts，因为它的API更灵活。

也有Zing图表声称使用SVG或Canvas，但没有查看它们。

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

可能还会研究Meteor Charts，它是基于uber快速KineticJS框架构建的：http ://meteorcharts.com/

我还发现，当我们将带有SVG图形的页面打印到PDF时，生成的PDF仍然包含基于矢量的图像，而如果您打印具有Canvas图形的页面，则生成的PDF文件中的图像将被光栅化。