原帖由 coredump 于 16-1-2012 21:43 发表
我很喜欢HTML5, 2011年几乎全年都在折腾canvas标准的实现
原帖由 trisun 于 16-1-2012 21:48 发表
用Vaadin + GWT 纯 Java ,比直接用Javascripts 好多了，可以很容易支持第三方Javascripts 库 （JSNI)，比直接用Javacripts 开发效率高。
原帖由 coredump 于 16-1-2012 23:00 发表
别太高兴, canvas绘图再利用硬件加速上还有很长的路要走, 所以大部分还是软件渲染, OpenGL和canvas的2d api有很多不可调和的矛盾.
如果是做game, 可以考虑直接上webgl
原帖由 trisun 于 16-1-2012 22:48 发表
用Vaadin + GWT 纯 Java ,比直接用Javascripts 好多了，可以很容易支持第三方Javascripts 库 （JSNI)，比直接用Javacripts 开发效率高。
原帖由 woodheadz 于 16-1-2012 23:10 发表
不是game，是正经八百的应用软件。
但我们的软件有大量的绘图和动画，所以基本上只能考虑html5. 我前两天直接用canvas做了几个效率测试（win平台，chrome和ie9），感觉效率实在很棒。
但因为这个平台太新，很担心 ...
原帖由 mason00 于 19-1-2012 13:23 发表
微软不是官方主推支持jquery吗？不过对于HTML5的特性是IE9跟不太上，所以微软也就没办法表明官方推荐什么库。反正我还是停留在HTML5之前的javascript库的，似乎是手机客户端对HTML5的特性比较需要，火了sencha哈。.N ...
原帖由 woodheadz 于 19-1-2012 11:50 发表
今天研究开源库Kinetic，主要想搞清楚它的hittest是怎么实现的，结果真是很让人吃惊。
Kinetic有个Shape对象，系统自动完成Shape对象的绘制准备工作（Scale，Rotate...）后调用回调传出context让调用端完成Shape的绘 ...
原帖由 woodheadz 于 19-1-2012 12:55 发表
我们的需求比较特别，重点在于绘图功能和图形功能的互动方面，而不是组件库上。所以得找找jquery，sencha之类的UI框架以外的东西
原帖由 coredump 于 19-1-2012 14:54 发表
在性能上Fabric就是用的多Canvas方式， 不过不是每个对象一个Canvas这么极端，因为这样反而完全丧失了Canvas做为2D底层绘图的优势，Fabric使用的是2层 Canvas。
https://github.com/kangax/fabric.js/wiki/Focus- ...
原帖由 coredump 于 19-1-2012 16:34 发表
我觉得这个之所以没想像中性能那么差， 是因为hitTest本来就是个慢速，低频率的事情， 现在的机器， 一个满屏的canvas， 重绘的FPS也很快， 如果跑到移动设备上， 硬件是差了， 可是屏幕也小了， 所以，都在可接受 ...
原帖由 coredump 于 20-1-2012 18:45 发表
在Canvas中检测鼠标事件有很多种有意思的方法， StackOverFlow上这个帖子很有参考价值
http://stackoverflow.com/questio ... thin-an-html-canvas
原帖由 woodheadz 于 24-1-2012 16:51 发表
考察了几个JS库，比较起来还是Kinetic和Easel JS最符合我们的需求，但都有各自的问题。
现在决定自己写一个，反正Kinetic和Easel JS都是MIT的授权协议，很多地方大可好好借鉴下他们的方式。
原帖由 woodheadz 于 24-1-2012 21:09 发表
搞了这几天，对canvas的强大简直十分满意
IE9现在对canvas的优化支持简直没得说，速度超快不说，还自带2D图形的抗锯齿。相比起来，Chrome绘图效率就明显不如，而且一旦对2d图形进行旋转缩放，最终的效果比ie就差太多 ...
原帖由 woodheadz 于 24-1-2012 22:16 发表
对了，还有个问题请教：
我这段时间看的js库基本上都采用每帧全canvas暴力刷新的方式完成动画。在高分辨率下，ie似乎还撑得住，但chrome就有点不行了。
如果修改为每帧刷新前先计算出无效区域，然后清除这个区域 ...
原帖由 coredump 于 24-1-2012 23:41 发表
我写的canvas实现因为不需要严格遵守canvas的规范, 就从实现上用了这个方式, 术语上称作tiled rendering(分片渲染).
有些canvas framework也用了这个概念(比如这个, 还有这个), 特别是在地图和游戏类型的应用中, ...
原帖由 coredump 于 25-1-2012 00:08 发表
这里有3个概念
1. tile size 每次绘制的小方块的大小
2. canvas size 整个画布的逻辑上的大小
3. canvas window size canvas这个元素的大小
如果2 > 3 而且 2> 1的时候, 就是你说的第一种的情况, 这个时候 ...
原帖由 woodheadz 于 24-1-2012 23:15 发表
我用这段代码：
var canvas = document.getElementById("myCanvas");
var context = canvas.getContext("2d");
context.fillStyle = "#FF0000";
context.fillRect(10, 10, 100, 50);
context.rotate(-Math. ...
原帖由 black_zerg 于 24-1-2012 23:45 发表
我当时找过检测点在polygon里，最后发现有个 W. Randolph Franklin 的代码 我给整理成了java的：
public static boolean pnpoly(int nvert, double[] vertx, double[] verty,
double testx, double testy) {
...
原帖由 black_zerg 于 24-1-2012 23:45 发表
按照我对canvas的理解，canvas最好依赖在后台的一个结构上做成mvc那种模型，因为本身canvas和vml svg什么的差很多,canvas画完了就完了，他也没有一个图形一个对象那种概念。
原帖由 black_zerg 于 25-1-2012 00:45 发表
我当时找过检测点在polygon里，最后发现有个 W. Randolph Franklin 的代码 我给整理成了java的：
public static boolean pnpoly(int nvert, double[] vertx, double[] verty,
double testx, double testy) {
...
原帖由 coredump 于 25-1-2012 01:06 发表
是滴, canvas和svg正好代表了2d绘图的两种风格
canvas是立即模式的代表, svg是保留模式的代表
直觉上来说, 我们总会觉得保留模式应该更受青睐一点, 可惜事实上相反, canvas这种立即模式成了香饽饽, svg却被打入 ...
只可惜命不好原帖由 woodheadz 于 24-1-2012 17:51 发表
考察了几个JS库，比较起来还是Kinetic和Easel JS最符合我们的需求，但都有各自的问题。
现在决定自己写一个，反正Kinetic和Easel JS都是MIT的授权协议，很多地方大可好好借鉴下他们的方式。
原帖由 coredump 于 25-1-2012 00:33 发表
这个只需要根据需要做简单判断就行了, 也就是决定具体的绘制区域上.
context2d 有clip方法, 所以即使具体的绘制没有严格遵守重绘区域的约定也可以剪裁掉, 而大部分底层clip实现可以保证足够的高效, 也就是说被裁减 ...
原帖由 coredump 于 25-1-2012 01:45 发表
没觉得你这个有什么特别的啊, 也不需要特别多的计算量. 效率提高是肯定的, 不过我建议还是估计下你是否真的需要, 因为很可能不是很需要.
优化的事情, 等不得不优化的时候再说, 因为这个基本上不会影响上层的逻辑 ...
原帖由 coredump 于 25-1-2012 02:07 发表
现在js库中这样做的少, 主要还是大部分都还没遇到性能问题, 但是一些正式的应用, 比如google maps, 它的很多理念都是这样的, 有时候还只能这样,别无他法.
程序猿旁边要是有个程序媛往往对缓解头大有帮助
)，这个矩阵在调用子对象的重绘方法前会被框架应用到context上， 所以子对象绘制自己时可以使用本地坐标。另外子对象的鼠标/触摸相关事件中也会由框架传子对象的本地坐标（支持旋转和缩放变换），方便编程。 原帖由 coredump 于 7-2-2012 19:10 发表
canvas的文本部分就是个灾难， 能不用完全不要用，切记！
http://simonsarris.com/blog/322- ... -considered-harmful
实际上可以直接用canvas结合div和其他html元素， 不一定所有东西都用canvas
原帖由 coredump 于 7-2-2012 19:10 发表
canvas的文本部分就是个灾难， 能不用完全不要用，切记！
http://simonsarris.com/blog/322- ... -considered-harmful
实际上可以直接用canvas结合div和其他html元素， 不一定所有东西都用canvas
原帖由 woodheadz 于 8-2-2012 11:23 发表
效果很让人吃惊啊... chrome下帧率翻了三倍，ie下帧率翻了两倍。
更让人惊喜的是ie下文本的显示质量大幅提升！ 我估计是因为ie只有在直接绘制图形、文字到屏幕的时候才会使用抗锯齿，而不对图片使用抗锯齿。
现在 ...
原帖由 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 ...
原帖由 woodheadz 于 8-2-2012 12:23 发表
效果很让人吃惊啊... chrome下帧率翻了三倍，ie下帧率翻了两倍。
更让人惊喜的是ie下文本的显示质量大幅提升！ 我估计是因为ie只有在直接绘制图形、文字到屏幕的时候才会使用抗锯齿，而不对图片使用抗锯齿。
现在 ...
"> <div><br></div><div> 1.卷屏 </div><div><br></div><div>卷屏我做了两个版本。第一个版本在canvas外部套一个DIV，然后利用DIV来卷屏。 我在Framwork里面加了一个ViewPort的概念，表示整个canvas上当前可见的范围。在刷新重绘的时候用这个ViewPort对重绘区域进行过滤，忽略掉不在ViewPort内的对象的重绘请求，以提高效率。</div><div>之所以一上来就选择这种方式，是因为当发生卷屏的时候，我可以通过ViewPort的变化计算出canvas上新显示出来区域，然后只重绘这些区域。我认为这样应该能极大地提高卷屏的效率，因为可以利用浏览器自身的图形能力完成原有区域的重绘。 </div><div>做完以后发现两个致命缺陷:首先div的卷屏动画在IE9下似乎不是很顺滑，有点像是因为对卷屏的位置ie会取整来计算（不确定）；其次Canvas的尺寸大小有限制，Chrome中到10000*10000以上就无法显示，IE 15000*15000以上就会崩溃。 后面这个缺陷对我们而言十分致命，因为我们需要非常大的绘制空间，而且因为会有很大倍数的缩放，所以对绘制区域的要求几乎是无限的。 </div><div>没办法，退而求其次，我使用自己进行坐标变换来完成卷屏的做法。这样程序要简单不少，而且绘制空间是虚拟的，没有尺寸限制。但每次卷屏的时候就必须把屏幕内的所有对象全部重绘。</div><div><br></div><div><br></div><div> 2.动画</div><div> 动画系统很简单，相对比较麻烦的easing函数算法，网上很容易就能找到MIT协议的代码。值得一提的内容就是调用端的包装。</div><div>我现在包装成这样的："> </div><div><br></div><div> 最后，要感谢下老丐无私的帮助，帮我解决了最为头疼也是影响巨大的文本渲染效率问题；也要谢谢black_zerg等几位提供意见的同学 <img src="./images/smilies/default/good.gif" border="0" smilieid="45" alt=""></div>
| 欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/) | Powered by Discuz! X3.2 |
