快速响应的交互式图表/graphics：SVG，Canvas，其他？
我正在尝试select正确的技术来更新一个基本上呈现可缩放，可移动graphics中的数千个点的项目。 目前使用Protovis的实施效果不佳。 看看这里：
http://www.planethunters.org/classify
完全缩小大约有2000点。 尝试使用底部的手柄放大一点，并拖动它平移。 你会发现它是非常不稳定的，你的CPU使用率可能会在一个内核上达到100％，除非你有一台非常快的计算机。 对焦点区域的每一个改变都会调用protovis来重绘，这相当慢，而且在绘制更多的点时会变得更糟。
我想对界面进行一些更新，并将底层的可视化技术更改为对animation和交互更加敏感。 从下面的文章中，似乎可以select另一种基于SVG的库或基于canvas的库：
从Protovis发展而来的d3.js是基于SVG的， 在渲染animation方面应该更好 。 不过，我很怀疑它的性能上限是多less。 出于这个原因，我还在考虑使用像KineticJS这样的基于canvas的库进行更彻底的检修。 然而，在我使用这种或那种方法过度使用之前，我想听听有人用这么多的数据完成了一个类似的Web应用程序，并得到他们的意见。
最重要的是性能，次要的重点是易于添加其他交互function和编程animation。 一次可能不会超过2000点，每个点都有小错误。 放大，缩小和平移需要平滑。 如果最近的SVG库在这方面比较体面，那么使用d3的难易程度可能会超过KineticJS的增加设置等。但是如果使用canvas有很大的性能优势，特别是对于电脑速度较慢的用户，那么我肯定会喜欢这样。
由使用SVG的NYTime制作的应用程序示例，但仍可以stream畅地animation： http ://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html 。 如果我可以得到这样的性能，而不必编写自己的canvas代码，那么我可能会selectSVG。
我注意到一些用户已经使用了与canvas渲染相结合的d3.js混合操作 。 不过，我无法在网上find很多关于这个post的文档，也没有联系到这个post的OP。 如果任何人有任何这样的DOM到canvas（ 演示 ， 代码 ）实现的经验，我想也听到你的。 这似乎是能够操纵数据和自定义控制如何呈现它（以及因此性能）的一个很好的混合体，但是我想知道是否必须将所有内容加载到DOM仍然会减慢速度。
我知道有一些类似于这个问题的现存问题，但是他们中的任何一个都没有问过同样的问题。 谢谢你的帮助。
后续 ：我最终使用的实现是在https://github.com/zooniverse/LightCurves
幸运的是，绘制2000圈是一个很容易testing的例子。 所以这里有四种可能的实现，Canvas和SVG两种：
- canvas几何缩放
- canvas语义缩放
- SVG几何缩放
- SVG语义缩放
这些示例使用D3的缩放行为来实现缩放和平移。 除了圆圈是以“canvas”还是“SVG”呈现外，其他的主要区别在于您是使用几何缩放还是语义缩放。
几何缩放意味着您对整个视口应用单个转换：放大时，圆圈变大。 对比语义缩放意味着您将变换应用到每个圆圈：放大时，圆圈保持相同的大小，但是展开。 Planethunters.org目前使用语义缩放，但考虑其他情况可能是有用的。
几何缩放简化了实现：您应用一次翻译和缩放，然后重新渲染所有的圆圈。 SVG实现特别简单，更新一个“transform”属性。 几何缩放例子的性能感觉绰绰有余。 对于语义缩放，您会注意到D3比Protovis快得多。 这是因为它为每个缩放事件做了很less的工作。 （Protovis版本必须重新计算所有元素的所有属性。）基于canvas的语义缩放比SVG更加快捷，但是SVG语义缩放仍然感觉响应。
然而，没有什么神奇的performance力，而这四种可能的方法并没有开始覆盖整个空间的可能性。 例如，您可以将几何缩放和语义缩放相结合，使用几何方法进行平移（更新“transform”属性），并在缩放时仅重绘各个圆圈。 你甚至可以将这些技术中的一个或多个与CSS3转换结合起来，以增加一些硬件加速（如在分层边缘捆绑的例子中 ），虽然这可能会很棘手的实现，并可能引入视觉工件。
尽pipe如此，我的个人偏好是尽可能多的使用SVG，当渲染成为瓶颈时，只使用Canvas作为“内部循环” 。 SVG有很多开发的便利，比如CSS，数据连接和元素检查器，从Canvas开始，这往往是过早的优化。 将Canvas与SVG结合起来，就像在Facebook上链接的可视化视图一样，这是一种灵活的方式，可以在保留大部分便利的同时保持最佳性能。 我还在Cubism.js中使用了这种技术，时间序列可视化的特殊情况适合于位图caching。
正如这些示例所示，即使D3的部分特定于SVG，也可以在Canvas中使用D3。 另请参阅此强制导向图和此碰撞检测示例 。
我认为，在你的情况下 ，canvas和svg之间的决定不是像“骑马”或驾驶“保时捷”之间的决定。 对我来说，更像是关于汽车颜色的决定。
让我解释一下：假设，基于框架的操作
- 画一颗星，
- 添加一颗星星
- 删除一颗星星
采取线性时间。 所以，如果你的框架决定是好的，它会快一点，否则会慢一点。
如果你继续假设这个框架是快速的，那么明显的是，性能的不足是非常明显的，因为大量的星星和处理它们是没有框架可以为你做的事情，至less我不知道对这个。
我想说的是，问题的基础导致了一个计算几何的基本问题，即： 范围search和另外一个计算机graphics： 细节层次 。
为了解决你的性能问题，你需要实现一个好的预处理器，这个预处理器能够非常快地find要显示的恒星，并且也许能够根据变焦聚集在一起的恒星。 保持你的观点生动和快速的唯一的东西是保持尽可能低的恒星数量。
正如你所说，最重要的是性能，比我倾向于使用canvas，因为它没有DOM操作。 它也提供了使用webGL的机会，这很大程度上提高了graphics性能。
顺便说一句：你检查paper.js ？ 它使用canvas，但模拟vectorgraphics。
PS： 在本书中，您可以find有关Web上的graphics，canvas，SVG和DHTML的技术，优缺点的详细讨论。
我最近在一个接近实时的仪表板上工作（每5秒刷新一次），并select使用使用canvas呈现的图表。
我们尝试了Highcharts（svg）和Canvasjs。 虽然Highcharts是一个梦幻般的图表API，并提供了更多的function，我们决定使用Canvasjs。
我们需要每个图表显示至less15分钟的数据（可以select最多两个小时的范围）。
所以15分钟：900点（每秒数据点）×2（线条和条形图组合图）×4图=总共7200点。
使用chrome分析器，使用Canvasjs，内存永远不会超过30MB，而Highcharts内存使用超过600MB。
另外刷新时间为5秒Canvasjs渲染分配响应更高，然后是Highcharts。
我们使用了一个定时器（setInterval 5秒）来进行4次REST API调用，从连接到Elasticsearch的后端服务器中获取数据。 每个图表更新为JQuery.post（）收到的数据。
这对于离线报道来说，我会selectHighcharts，因为它更加灵活的API。
还有Zing图表声称使用SVG或Canvas，但没有看过他们。
性能确实非常关键时，应该考虑帆布。 SVG的灵活性。 不是说canvas框架不够灵活，但是为了获得与svg框架相同的function，canvas框架需要更多的工作。
也可以看看meteor图，这是build立在超级快速的KineticJS框架之上： http ://meteorcharts.com/
