And*_*Mao 112 html5 svg canvas d3.js kineticjs
我正在尝试选择合适的技术来更新项目,该项目基本上可以在可缩放的可缩放图形中渲染数千个点.使用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这样的基于画布的库进行更彻底的改造.然而,在我使用一种或另一种方法之前,我想听听那些使用这么多数据做过类似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操作和画布渲染.但是,我无法在网上找到很多关于此的文档或与该帖子的OP联系.如果有人有任何使用DOM-to-Canvas(演示,代码)实现的经验,我也想听听你的意见.它似乎是一个很好的混合体,能够操纵数据和自定义控制如何渲染它(以及因此性能),但我想知道是否必须将所有内容加载到DOM仍然会减慢速度.
我知道有一些类似于这个问题的现有问题,但它们都没有提出同样的问题.谢谢你的帮助.
后续行动:我最终使用的实现是https://github.com/zooniverse/LightCurves
mbo*_*ock 181
幸运的是,绘制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的.另请参见此力导向图和此碰撞检测示例.
我认为在你的情况下,canvas和svg之间的决定并不像是"骑马"或驾驶"保时捷"之间的决定.对我来说,更像是关于汽车颜色的决定.
让我解释一下:假设,基于框架的操作
采取线性时间.所以,如果您对框架的决定是好的,那么它会更快,否则会慢一些.
如果你继续假设框架速度很快,那么很明显导致性能不足导致大量的星星和处理它们是框架无法为你做的事情,至少我不知道对这个.
我想说的是问题的基础导致计算几何的基本问题,即:范围搜索和计算机图形的另一个:细节层次.
为了解决您的性能问题,您需要实现一个良好的预处理器,它能够非常快速地找到要显示的星星,并且可能能够根据缩放比例聚集在一起的星星.让你的视野生动而快速的唯一因素就是尽可能地保持星星的数量.
如你所说,最重要的是性能,而不是我倾向于使用canvas,因为它没有DOM操作.它还提供了使用webGL的机会,这大大提高了图形性能.
顺便说一句:你检查过paper.js吗？它使用画布,但模拟矢量图形.
PS:在本书中,您可以找到关于Web上的图形,技术,canvas,SVG和DHTML的优缺点的非常详细的讨论.
我最近在一个近乎实时的仪表板上工作(每5秒刷新一次)并选择使用使用画布渲染的图表.
我们尝试了Highcharts(基于SVG的JavaScript Charting库)和CanvasJS(基于Canvas的JavaScript Charting库).虽然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框架相同的功能,canvas框架需要做更多的工作.
| 归档时间： |
|
| 查看次数： |
35997 次 |
| 最近记录： |