快速和反应灵敏的交互式图表/图形：SVG，Canvas，其他？ [英] Fast and responsive interactive charts/graphs: SVG, Canvas, other?
问题描述
我试图选择合适的技术来更新项目，该项目基本上在可缩放，可移动的图形中呈现数千个点。目前的实施，使用Protovis，表现不佳。请点击此处：
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 ）进行更全面的检修。然而，在我使用某种方法太深入之前，我想听到一个人做了一个类似的网络应用程序与这么多的数据，并得到他们的意见。
最重要的是性能，第二个重点是轻松添加其他交互功能和编程动画。一次可能不会有超过2000个点，每个点上都有小的误差棒。 放大，缩小和平移需要平滑。如果最新的SVG库在这一点体面，那么也许使用d3的容易超过KineticJS增加的设置等。但是如果有一个巨大的性能优势使用画布，特别是对于较慢的计算机的人，那么我一定会喜欢这样。
NYTimes制作的应用程序示例使用SVG，但仍然动画接受顺利：
http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html 。如果我可以得到这个性能，而不必编写自己的画布代码，我可能去SVG。
我注意到一些用户使用了一个混合< a href =http://stackoverflow.com/questions/12098286/canvas-tooltip-to-appear-outside-canvas> d3.js操作与画布渲染相结合。但是，我找不到很多关于这个在线文档或与该帖的OP联系。如果任何人有任何经验，做这种DOM到画布（演示，代码）实现，我也想听到你的声音。它似乎是一个很好的混合，能够操纵数据和自定义控制如何渲染（因此性能），但我想知道是否必须加载到DOM仍然会慢下来。 / p>
我知道有一些现有的问题与这个类似，但是没有一个问题是相同的。感谢您的帮助。
后续：我最终使用的实现是在 https://github.com/zooniverse/LightCurves
幸运的是，绘制2000圆是一个很容易测试的例子。所以这里有四个可能的实现，Canvas和SVG各有两个：
这些示例使用D3的缩放行为实现缩放和平移。除了圆形是以Canvas还是SVG呈现之外，其他主要区别是您是否使用几何或语义缩放
。几何缩放意味着对整个视口应用单个变换：放大时，圆圈变大。对比的语义放大意味着您单独对每个圆应用变换：放大时，圆形保持相同的大小，但它们展开。 Planethunters.org目前使用语义缩放，但它可能有助于考虑其他情况。
几何缩放简化了实现：您应用一次翻译和缩放，然后全部这些圆圈被重新渲染。 SVG实现特别简单，更新单个transform属性。两个几何缩放示例的性能感觉足够。对于语义缩放，您会注意到D3比Protovis显着更快。这是因为它为每个缩放事件做了很少的工作。 （Protovis版本必须重新计算所有元素的所有属性。）基于Canvas的语义缩放比SVG有点拉链，但是SVG语义缩放仍然感觉响应。
但是没有什么神奇的性能表现，这四种可能的方法并没有开始覆盖整个空间的可能性。例如，您可以结合几何和语义缩放，使用几何方法平移（更新变换属性），并且仅在缩放时重绘单个圆圈。你可能甚至可以结合一个或多个这些技术与CSS3变换来添加一些硬件加速（如在分层边缘绑定示例），虽然这可能是棘手的实施，并可能引入视觉工件。
不过，我个人的偏好是在SVG中保持尽可能多的效果，并且在渲染是瓶颈时使用Canvas仅用于内部循环。 SVG有很多方便开发 - 例如CSS，数据连接和元素检查器 - 它通常是从Canvas开始的过早优化。将Canvas与SVG结合使用，如在您链接的Facebook IPO可视化中，是一种灵活的方式来保留大多数这些便利，同时仍然保持最佳性能。我也在 Cubism.js 中使用了这种技术，其中时间序列可视化的特殊情况到位图缓存。
如这些例子所示，你可以使用D3和Canvas，即使D3的部分是SVG特定的。另请参阅此强制导向图和此碰撞检测示例。
I am trying to choose the right technology to use for updating a project that basically renders thousands of points in a zoomable, pannable graph. The current implementation, using Protovis, is underperformant. Check it out here:
http://www.planethunters.org/classify
There are about 2000 points when fully zoomed out. Try using the handles on the bottom to zoom in a bit, and drag it to pan around. You will see that it is quite choppy and your CPU usage probably goes up to 100% on one core unless you have a really fast computer. Each change to the focus area calls a redraw to protovis which is pretty darn slow and is worse with more points drawn.
I would like to make some updates to the interface as well as change the underlying visualization technology to be more responsive with animation and interaction. From the following article, it seems like the choice is between another SVG-based library, or a canvas-based one:
http://www.sitepoint.com/how-to-choose-between-canvas-and-svg/
d3.js, which grew out of Protovis, is SVG-based and is supposed to be better at rendering animations. However, I'm dubious as to how much better and what its performance ceiling is. For that reason, I'm also considering a more complete overhaul using a canvas-based library like KineticJS. However, before I get too far into using one approach or another, I'd like to hear from someone who has done a similar web application with this much data and get their opinion.
The most important thing is performance, with a secondary focus on ease of adding other interaction features and programming the animation. There will probably be no more than 2000 points at once, with those small error bars on each one. Zooming in, out, and panning around need to be smooth. If the most recent SVG libraries are decent at this, then perhaps the ease of using d3 will outweigh the increased setup for KineticJS, etc. But if there is a huge performance advantage to using a canvas, especially for people with slower computers, then I would definitely prefer to go that way.
Example of app made by the NYTimes that uses SVG, but still animates acceptably smoothly: http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html . If I can get that performance and not have to write my own canvas drawing code, I would probably go for SVG.
I noticed that some users have used a hybrid of d3.js manipulation combined with canvas rendering. However, I can't find much documentation about this online or get in contact with the OP of that post. If anyone has any experience doing this kind of DOM-to-Canvas (demo, code) implementation, I would like to hear from you as well. It seems to be a good hybrid of being able to manipulate data and having custom control over how to render it (and therefore performance), but I'm wondering if having to load everything into the DOM is still going to slow things down.
I know that there are some existing questions that are similar to this one, but none of them exactly ask the same thing. Thanks for your help.
Follow-up: the implementation I ended up using is at https://github.com/zooniverse/LightCurves
Fortunately, drawing 2000 circles is a pretty easy example to test. So here are four possible implementations, two each of Canvas and SVG:
These examples use D3's zoom behavior to implement zooming and panning. Aside from whether the circles are rendered in Canvas or SVG, the other major distinction is whether you use geometric or semantic zooming.
Geometric zooming means you apply a single transform to the entire viewport: when you zoom in, circles become bigger. Semantic zooming in contrast means you apply transforms to each circle individually: when you zoom in, the circles remain the same size but they spread out. Planethunters.org currently uses semantic zooming, but it might be useful to consider other cases.
Geometric zooming simplifies the implementation: you apply a translate and scale once, and then all the circles are re-rendered. The SVG implementation is particularly simple, updating a single "transform" attribute. The performance of both geometric zooming examples feels more than adequate. For semantic zooming, you'll notice that D3 is significantly faster than Protovis. This is because it's doing a lot less work for each zoom event. (The Protovis version has to recalculate all attributes on all elements.) The Canvas-based semantic zooming is a bit more zippy than SVG, but SVG semantic zooming still feels responsive.
Yet there is no magic bullet for performance, and these four possible approaches don't begin to cover the full space of possibilities. For example, you could combine geometric and semantic zooming, using the geometric approach for panning (updating the "transform" attribute) and only redrawing individual circles while zooming. You could probably even combine one or more of these techniques with CSS3 transforms to add some hardware acceleration (as in the hierarchical edge bundling example), although that can be tricky to implement and may introduce visual artifacts.
Still, my personal preference is to keep as much in SVG as possible, and use Canvas only for the "inner loop" when rendering is the bottleneck. SVG has so many conveniences for development—such as CSS, data-joins and the element inspector—that it is often premature optimization to start with Canvas. Combining Canvas with SVG, as in the Facebook IPO visualization you linked, is a flexible way to retain most of these conveniences while still eking out the best performance. I also used this technique in Cubism.js, where the special case of time-series visualization lends itself well to bitmap caching.
As these examples show, you can use D3 with Canvas, even though parts of D3 are SVG-specific. See also this force-directed graph and this collision detection example.
这篇关于快速和反应灵敏的交互式图表/图形：SVG，Canvas，其他？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
