HTML5提供了绘制圆弧的函数arc其定义为:
Arc(x,y,radius,startAngle,endAngle,antiClockwise)
该函数的最后一个参数表示是顺时针还是逆时针绘制圆弧,在Opera下最后一个参数必须输入,否则函数会出错,圆弧无法绘制出来。而在IE9,FF, Chrome, Safari下最后一个参数可以不指定。
这个主要通过html5的isPointInPath可以发现,代码如下
<DIV id="testDiv"> <canvas id="test"width="500" height ="500"></canvas> </DIV> <SCRIPT> var canvasNode =document.getElementById('test'); var ctx = canvasNode.getContext('2d'); ctx.translate(8,8); ctx.beginPath(); ctx.arc(0,0,8,0,2*Math.PI,true); ctx.closePath(); ctx.stroke(); alert(ctx.isPointInPath(8,8)); </SCRIPT>
以下是代码片断
destroy: function() { console.log('args number:' +arguments.length + (arguments.length > 0?' first arg:' + arguments[0]:''));..... this.inherited(arguments); }
FF 6: args number:1 firstarg:0 args number:0 args number:1 firstarg:-1 Chrome: args number:0 args number:0 args number:0 args number:0 args number:0 args number:0 Safari: args number:0 args number:0 args number:0 args number:0 args number:0 IE9 日志: args number:0 日志: args number:0 日志: args number:0 日志: args number:0 日志: args number:0
当Dom结构比较复杂的时候,以WebKit为核心的浏览器在处理contentable=true的DIV时存在BUG,使得该属性失效。这个问题的解决方法为在DIV外增加一个IFRAME使得该DIV和外界Dom隔离,任你外面如何复杂,IFRAME里面的还是很简单的。
这个标题比较大,这里只谈一下调试器和浏览器性能
由于项目使用了dojo,dojo的一大特点就是JS动态加载,其原理是JS执行过程中通过调用dojo.require这个API向服务器发送http请求,获得JS文本,再通过eval函数执行对应的js代码。
对于这样的文本,chrome的调试器可以直接显示对应的文件列表,chrome15以上版本会对这个JS的目录做了个整理输出。在IE下这些匿名JS全是一些编号,但是选择这些JS文本可以显示。在FireBug下,如果是源码包,可以看到这些JS。如果是发布包这些JS也是一些编号,但是比较糟糕的是,JS文本看不到。Safari调试器完全感知不到这些JS。
相比于chrome/safari。IE,Firebug要求重新载入JS。另外除了FireBug其余浏览器的调试器都提供了代码格式化工具,这样非常方便对于混淆JS的调试。
IE8、9的调试器都提供了查看器功能。在查看器签页,点击开始采样(IE8下为开始配置文件),浏览器开始记录从现在开始,JS函数的执行情况。点击结束采样,下方的表格会出现所有执行的JS函数列表,这个功能对于一个新手定位问题非常的有帮助。同时显示的JS执行情况支持调用栈视图,非常的棒。
|
匿名JS处理 |
调试时是否需要重新载入 |
调试器内的JS格式化 |
内置JS执行情况统计工具 |
Chrome |
最佳,可以很清楚的显示 |
不需要 |
支持 |
NA |
IE8,9 |
一般,可以显示文本,但不能显示文件名称 |
需要 |
支持 |
有 |
FireFox |
一般 |
需要 |
不支持 |
NA |
Safari |
差,不能显示 |
不需要 |
支持 |
NA |
通过以上表格,我个人感觉Chrome的调试是非常便利的,确实应了一句话“Chrome能蚕食FireFox的原因之一就是WEB开发人员越来越喜欢使用Chrome的调试器”。 IE表现中庸, Firebug比较一般。
项目中存在一个大表格,有两百条数据,每一列都用了dojo的FilteringSelect,。所以展现这样一个表格非常的耗时(当然,后续的设计作了优化)。在这样的一个场景下,各浏览器的表现分别为
FireFox和Chrome/Safari在界面失去响应近25 秒后弹出了提示框------问用户是否继续等待。这个时候点击确定后继续等待,界面还是可以出来。
IE在界面失去响应近30秒后,界面还是出来了。
在Opera下界面随着脚本的执行不断地变化,11秒就全部搞定,果然是最快的浏览器。
从上面我个人感觉FireFox和Chrome的处理方式不太好,弹出的对话框很容易让人误以为脚本存在问题,导致浏览器忙;Opera是一边渲染一边执行,给用户的感觉最佳。IE则是一个闷头做事的小伙子,只要能搞定,就决不吭声,虽然它不快:)