javascript库求推荐

woodheadz

原帖由 coredump 于 25-1-2012 00:33 发表

                               
登录/注册后可看大图

这个只需要根据需要做简单判断就行了, 也就是决定具体的绘制区域上.

context2d 有clip方法, 所以即使具体的绘制没有严格遵守重绘区域的约定也可以剪裁掉, 而大部分底层clip实现可以保证足够的高效, 也就是说被裁减 ...

可能我之前没表达清楚：
canvas重绘的方式是先清除，然后重新绘制新的图像。我的意思是清除时只清除发生变化的部分，然后只掉用和发生变化部分相关的绘图代码绘制新图。此时如果有某一部分代码绘制的图像只有一部分被包含在被清除的区域，而这个图像中又包含了半透明的像素的话，这些在区域外的点在重绘后就是错的。加入clip区域后就能防止这种情况的出现。
clip区域处理多余图像的效率我到是不担心，我担心的是这种尽量减小重绘区域面积的方式能多大程度上提高绘图效率？
因为我还需要处理我的framework里图像对象之间的亲子复合关系，还计划支持图形对象的旋转缩放，所以要想得出这个清除区域的话就涉及到大量的坐标映射计算，工作量不小。所以我想先确认下这个问题

[ 本帖最后由 woodheadz 于 25-1-2012 01:45 编辑 ]

woodheadz

原帖由 coredump 于 25-1-2012 01:11 发表

                               
登录/注册后可看大图

我们的Qt QML也是保留模式的经典, JavaFX也算一个了.

参与一个伟大产品的制作过程，感觉很爽吧？

coredump

没觉得你这个有什么特别的啊, 也不需要特别多的计算量.  效率提高是肯定的, 不过我建议还是估计下你是否真的需要, 因为很可能不是很需要.

优化的事情, 等不得不优化的时候再说, 因为这个基本上不会影响上层的逻辑.

coredump

原帖由 woodheadz 于 25-1-2012 00:44 发表

                               
登录/注册后可看大图

参与一个伟大产品的制作过程，感觉很爽吧？

什么感觉都有, 有时候觉得别人都很聪明, 自己很白痴.

而且做实现的, 很多时候其实不如做上层应用带来的感觉爽.

woodheadz

原帖由 coredump 于 25-1-2012 01:45 发表

                               
登录/注册后可看大图

没觉得你这个有什么特别的啊, 也不需要特别多的计算量.  效率提高是肯定的, 不过我建议还是估计下你是否真的需要, 因为很可能不是很需要.

优化的事情, 等不得不优化的时候再说, 因为这个基本上不会影响上层的逻辑 ...

我这两天用全canvas重绘的方式做了个demo，在chrome中高分辨率下明显感觉到动画不顺。正式的产品动画还会复杂很多，所以我很担心，这涉及到可行性的问题。
我打算用的这个方式在gdi年代很常见，但这段时间看的js库没一个这么干的，所以才会产生疑惑。
这样做计算量的确不会大，但这些算法对于我这个不大会用矩阵做坐标变换的程序猿而言，想起来还是有点头大

coredump

现在js库中这样做的少, 主要还是大部分都还没遇到性能问题, 但是一些正式的应用, 比如google maps, 它的很多理念都是这样的, 有时候还只能这样,别无他法.

程序猿旁边要是有个程序媛往往对缓解头大有帮助

woodheadz

原帖由 coredump 于 25-1-2012 02:07 发表

                               
登录/注册后可看大图

现在js库中这样做的少, 主要还是大部分都还没遇到性能问题, 但是一些正式的应用, 比如google maps, 它的很多理念都是这样的, 有时候还只能这样,别无他法.

程序猿旁边要是有个程序媛往往对缓解头大有帮助

嘿嘿，刚在EsealJS库里找到个Matrix对象，看起来挺好用的，一定程度上缓解了没有程序媛在身边的时候头大的问题

woodheadz

EasealJS库的Matrix有bug，kill了我一早上的时间     
看来核心技术还得自己掌握

woodheadz

初步完工了一个简单的UI框架，把前面基于Kinetic做的demo移植后重新跑起来了。
新的框架的实现方式是这样的：
1.支持复合关系，即UI对象之间的父子关系。子对象除了相对于父对象的X，Y坐标外还可以设置缩放、旋转。这部分使用了一个矩阵来进行坐标变换(JS想找个好用的矩阵类怎么就那么难 )，这个矩阵在调用子对象的重绘方法前会被框架应用到context上， 所以子对象绘制自己时可以使用本地坐标。另外子对象的鼠标/触摸相关事件中也会由框架传子对象的本地坐标（支持旋转和缩放变换），方便编程。

2.提供了ClipToBounds属性，设置后可以确保子对象在父对象边界外的内容不被显示，也不被hittest感知。这部分用canvas的clip很好实现，hittest的时候检查下这个属性即可。

3.Hittest学习了Kinetic的做法，但在做test之前先使用bounds过滤一下，大幅提高效率。

4.重绘方面现在暂时使用全屏重绘的方式，回头计划修改为部分重绘，到时候再附上效率测试报告

5.做了个十分简单但很好用的动画类，JS干这种活真是不赖。现在还少了一些ease函数，回头上网找找算法。

新框架在使用上比Kinetic和easelJS要复杂些（因为要提供对象的长宽），但效率上我相信会强一点。如果将来老板同意开源，我考虑使用这种方式自动帮助用户计算长宽：覆盖context的所有绘图方法，在绘图前先根据绘图内容自动修改长和宽。 这样感觉就很强悍了。这点现在对我们将要开发的产品没啥意义，因为所有绘制的东西的尺寸数据模型上都有详细的记录。
   
另外关于卷屏和全屏缩放，虽然用canvas实现会很简单，但因为涉及全屏刷新，效率太低。我在想能不能用css从canvas外部来实现？ 这样我就只需要重绘新显示出来的部分即可，避开全屏刷新。

总的感觉，虽然我还是很不喜欢Javascript，但不得不承认js的开发效率实在不错

woodheadz

编了个程序测试浏览器的浮点运算性能，结果太让人吃惊了。
chrome居然1秒多就完成任务，firefox 6秒多而IE9居然要花190多秒
同样的计算C#也要6秒多。
chrome快得太变态，而IE慢得也太变态了

IE看来就是绘图性能牛逼，js执行性能差的不是一点半点

black_zerg

javascript 动画需要考虑性能，因为javascript是单线程。我本来的动画效果蛮好，到一个烂机器上一看悲剧得不行

woodheadz

原帖由 black_zerg 于 2-2-2012 19:04 发表

                               
登录/注册后可看大图

javascript 动画需要考虑性能，因为javascript是单线程。我本来的动画效果蛮好，到一个烂机器上一看悲剧得不行

现在我也就是在和性能做搏斗...
我的引擎现在效率已经能达到将近Kinetic的一倍， 我的显示器（2560×1600）上，IE9全屏动画基本上接近可以接受的效率。但在chrome上还是不行。另外在IPad上以IPad的分辨率来也不够，很头疼啊....

还有就是使用canvas绘制出来的文本边缘发虚（估计是抗锯齿的缘故），一旦字体小了识别方面可能就有问题。
现在我在考虑使用svg绘制文本，另外打印的时候直接把整个图绘制成svg打印。
这样就需要对canvas的context做一个抽象。之前好像见过类似的开源项目，应该不会很复杂吧...

woodheadz

SVG的绘制速度一般而言肯定慢于canvas，但我忽然想到如果做动画，尤其是高分辨率下以移动对象为主的全屏动画我觉得就不一定了。因为SVG的重绘策略由浏览器决定，在移动对象的动画中浏览器是有可能通过缓存、显卡buffer操作等策略极大提升效率的。

因为要用到SVG，所以顺便对SVG和canvas来了个对比测试，测试方式是画1000个各色矩形，在矩形上绘制文本， 然后用动画随机移动。

结果相当有趣。

— | canvas | svg
ie9 | 15 | 11
chrome | 7.5 | 9

这是在FullHD的分辨率下测得的数据。

也就是说在这个测试中IE的canvas来得比svg快而在chrome中则反了过来。
文本渲染的质量svg明显强过canvas，编程方面svg也有明显的优势。

真难以取舍啊....

coredump

canvas的文本部分就是个灾难， 能不用完全不要用，切记！
http://simonsarris.com/blog/322- ... -considered-harmful

实际上可以直接用canvas结合div和其他html元素， 不一定所有东西都用canvas

woodheadz

原帖由 coredump 于 7-2-2012 19:10 发表

                               
登录/注册后可看大图

canvas的文本部分就是个灾难， 能不用完全不要用，切记！
http://simonsarris.com/blog/322- ... -considered-harmful

实际上可以直接用canvas结合div和其他html元素， 不一定所有东西都用canvas

谢谢这个链接，看起来对我非常有用。
我也发现文本渲染的效率及其低下了，不管是canvas还是svg，去掉文本之后桢率都能轻松跑到40以上。这两天正在为此头疼呢
明天试试你链接里的方法

woodheadz

原帖由 coredump 于 7-2-2012 19:10 发表

                               
登录/注册后可看大图

canvas的文本部分就是个灾难， 能不用完全不要用，切记！
http://simonsarris.com/blog/322- ... -considered-harmful

实际上可以直接用canvas结合div和其他html元素， 不一定所有东西都用canvas

效果很让人吃惊啊... chrome下帧率翻了三倍，ie下帧率翻了两倍。
更让人惊喜的是ie下文本的显示质量大幅提升！ 我估计是因为ie只有在直接绘制图形、文字到屏幕的时候才会使用抗锯齿，而不对图片使用抗锯齿。
现在考虑继续测试下直接使用html渲染文本的效果

coredump

原帖由 woodheadz 于 8-2-2012 11:23 发表

                               
登录/注册后可看大图

效果很让人吃惊啊... chrome下帧率翻了三倍，ie下帧率翻了两倍。
更让人惊喜的是ie下文本的显示质量大幅提升！ 我估计是因为ie只有在直接绘制图形、文字到屏幕的时候才会使用抗锯齿，而不对图片使用抗锯齿。
现在 ...

要求请客， 发工资

woodheadz

原帖由 coredump 于 8-2-2012 16:23 发表

                               
登录/注册后可看大图

要求请客， 发工资

过来，请你喝啤酒

findcaiyzh

原帖由 coredump 于 19-1-2012 14:46 发表

                               
登录/注册后可看大图

如果不需要太多的UI组件框架，而只是焦点在Canvas绘图上，也可以研究下 Fabric
https://github.com/kangax/fabric.js/
后台建立在Node.js上， 目标之一就是速度。
Demo：http://kangax.github.com/fabric.js/ki ...

Fabric的demo是用到了Html5了吗？我看chrome和IE9都能支持的挺好。
我们单位可能会用到这类的库。

findcaiyzh

Fabric的demo  IE8也可以。。
回头研究下。

findcaiyzh

woodheadz和coredump你们两个都是高手啊。

woodheadz

原帖由 woodheadz 于 8-2-2012 12:23 发表

                               
登录/注册后可看大图

效果很让人吃惊啊... chrome下帧率翻了三倍，ie下帧率翻了两倍。
更让人惊喜的是ie下文本的显示质量大幅提升！ 我估计是因为ie只有在直接绘制图形、文字到屏幕的时候才会使用抗锯齿，而不对图片使用抗锯齿。
现在 ...

尝试了直接使用Html，效率只比SVG稍微快一点点
决定使用纯canvas来渲染文本了！
我把那个做法改进了一点点，绘制文本后缓存图片而不是canvas，效率基本没有影响，而内存占用从320M降低到了50M

woodheadz

下一步的问题就是如何完成文本的排版，主要是分行. 因为要考虑支持多语言的问题，主要是要支持由右到左的语言比如阿拉伯语和希伯来语，所以很头痛啊...
我现在甚至都找不到判定一个字符串是不是由右到左的语言的方法

coredump

在canvas里搞定一个完整的Text layout引擎啊， 这个搞得有点太大了， 你可想想清楚啊， 工作量不是一点半点。

woodheadz

原帖由 coredump 于 9-2-2012 14:10 发表

                               
登录/注册后可看大图

在canvas里搞定一个完整的Text layout引擎啊， 这个搞得有点太大了， 你可想想清楚啊， 工作量不是一点半点。

不用完整的，只需要完成基本的分行，分段功能就可以，图文混排啥的都不用。
应该挺简单的，只是我还没找到识别右-左语言的方法   
实在不行我就针对单个字符来判断是不是希伯来文或者阿拉伯文

woodheadz

我们产品第一个原型的开发已经接近完成，这个UI framework的开发也基本结束。原型系统模拟了真实运行时的一些较复杂的动画场景，在1920*1080的分辨率下基本能够稳定在55~60帧顺畅运行，让人非常满意。
什么事都要有头有尾，我上来继续对UI Framework里面之前没有提的部分做个交代 <img src="./images/smilies/default/lol.gif" border="0" smilieid="12" alt="">&nbsp;<div><br></div><div>&nbsp;1.卷屏&nbsp;</div><div><br></div><div>卷屏我做了两个版本。第一个版本在canvas外部套一个DIV，然后利用DIV来卷屏。 我在Framwork里面加了一个ViewPort的概念，表示整个canvas上当前可见的范围。在刷新重绘的时候用这个ViewPort对重绘区域进行过滤，忽略掉不在ViewPort内的对象的重绘请求，以提高效率。</div><div>之所以一上来就选择这种方式，是因为当发生卷屏的时候，我可以通过ViewPort的变化计算出canvas上新显示出来区域，然后只重绘这些区域。我认为这样应该能极大地提高卷屏的效率，因为可以利用浏览器自身的图形能力完成原有区域的重绘。&nbsp;</div><div>做完以后发现两个致命缺陷:首先div的卷屏动画在IE9下似乎不是很顺滑，有点像是因为对卷屏的位置ie会取整来计算（不确定）；其次Canvas的尺寸大小有限制，Chrome中到10000*10000以上就无法显示，IE 15000*15000以上就会崩溃。 后面这个缺陷对我们而言十分致命，因为我们需要非常大的绘制空间，而且因为会有很大倍数的缩放，所以对绘制区域的要求几乎是无限的。&nbsp;</div><div>没办法，退而求其次，我使用自己进行坐标变换来完成卷屏的做法。这样程序要简单不少，而且绘制空间是虚拟的，没有尺寸限制。但每次卷屏的时候就必须把屏幕内的所有对象全部重绘。</div><div><br></div><div><br></div><div>&nbsp;2.动画</div><div>&nbsp;动画系统很简单，相对比较麻烦的easing函数算法，网上很容易就能找到MIT协议的代码。值得一提的内容就是调用端的包装。</div><div>我现在包装成这样的：
shape.moveTo(100, 100).onFinished(function(){shape.alphaTo(0).onFinished(function(){shape.parent.removeChild(shape);})});&nbsp;</div><div>这行代码执行后，shape会移动到100,100，然后逐渐变透最后后消失。&nbsp;</div><div>本来想包装成这样：</div><div>shape.moveTo(100,100).alphaTo(0).onFinished(function(){shape.parent.removeChild(shape);});&nbsp;</div><div>但发现要实现这个有点复杂，所以放弃了。&nbsp;
</div><div><br></div><div>动画系统还有一个细节，我提供了一个function beginInvoke(callback)方法，传入一个回调函数后，这个回调函数会在下一帧动画渲染执行前被执行。这个小功能在绘图逻辑十分复杂的情况下十分有用。</div><div>以我们的系统为例：我们的系统是data=&gt;viewModel=&gt;view的结构，因为呈现逻辑十分复杂，所以在data和view之间增加了一个viewModel层，负责根据data计算如何呈现。整个ViewModel层全部运行在beginInvoke回调的函数中，这样当用户修改data造成data的多处关联变动之后，只需要进行一次viewModel的计算即可。&nbsp;</div><div><br></div><div>&nbsp;3.其它&nbsp;</div><div>感觉javascript执行起来还是比较慢。做复杂的应用务必要考虑这点。我在做1000个对象的动画测试时，发现仅仅只是坐标矩阵的计算，就能让帧率从60帧降到40帧。Chrome js效率快得变态，而IE... 哎....&nbsp;</div><div><br></div><div>&nbsp;我和老板提了下把这个framework开源的问题，老板似乎很不乐意，因为转移到html5/js平台肯定是个趋势，但这个平台上目前还没有很棒的框架。如果我们公司的竞争对手得到这个framework，必然对他们会有很大的帮助。这种框架本身应用领域属于小众市场，我们也不大可能靠他获得什么利益。<img src="./images/smilies/default/sad.gif" border="0" smilieid="2" alt="">&nbsp;</div><div><br></div><div>&nbsp;最后，要感谢下老丐无私的帮助，帮我解决了最为头疼也是影响巨大的文本渲染效率问题；也要谢谢black_zerg等几位提供意见的同学 <img src="./images/smilies/default/good.gif" border="0" smilieid="45" alt=""></div>

[ 本帖最后由 woodheadz 于 25-2-2012 15:58 编辑 ]

fcq731

用extjs也不错

black_zerg

强，搞个在线demo瞧瞧啊，就是看看，不要代码。或者搞个utube录像好了，省得怕泄露

woodheadz

原帖由 black_zerg 于 26-2-2012 19:48 发表

                               
登录/注册后可看大图

强，搞个在线demo瞧瞧啊，就是看看，不要代码。或者搞个utube录像好了，省得怕泄露

回头产品发布了就能给大家看效果了
其实这个framework不是很复杂。只要避开我前面走过的一些弯路，你也能很快做出一个来