army8735

感慨万千啊，mmorpg，聊天、任务、战斗……刚开始随即夭折，只保留有这2段视频和1张截图了。《Fantasy Sky》——纪念那些逝去的代码，还有青春。

http://www.francois-tarlier.com/blog/marilena-opencv-port-to-actionscript-3-as3-flash/
无意间发现的，一个叫做Ohtsuka Masakazu的家伙（看名字像是日籍人士），将著名的opencv改写出一个as3版。
而后，另外一个人改进了它，主要是优化性能：http://www.quasimondo.com/archives/000687.php#000687
我做了个测试，的确对人脸识别得挺准的。只是图片太大时会抛出异常，而且根据不同的设置不同的图片识别速度也不一样。用我的2张老照片试试：

是否某些sns的相册系统或者其它的地方也可以考虑下呢？

http://flashteam.tencent.com/post/18/externalinterface-and-javascript/
tencent的flashteam发布过2篇关于ExternalInterface的详解以及优化，着实给广大人民群众带来了不少利益。但是其中有点隐患。比如文中所说的__flash__escapeXML优化：一是少了对&符号的转义，这个一般情况下的确可以省略，因为很少字符串数据中会出现&符号，但是一旦出现就会被转化为&；二是可怜的<被写成了≶，说实话我为了这个bug郁闷了几个星期才发现是字母拼错了……
加入&的解析，不能直接加在正则替换callback中，因为某些隐秘的情况下会出现重复转义&的情况，而且非常难查。所以5次转义最好情况也只能被优化为2次：
//覆盖flash默认通信方法，提高性能
window.__flash__escapeXML = function(s) {
var keywords = {
“\”" : “"”,
“<” : “&lt;”,
“>” : “&gt;”,
“\”" : “&apos;”
};
return s.replace(/&/g, “&amp;”).replace(/(['"<>])/g, function(a, b) {
var…

http://bugs.adobe.com/jira/browse/FP-240
不多说，回复中有个解决办法，利用jQuery的live（为所有可能的object对象绑定侦听）：
$(document).ready(function(){
gPageTitle = $(“title”).html();
$(“object”).live(“mouseenter mouseleave mousedown mouseup”,function(){
document.title = gPageTitle;
});
});
想触发对object的wmode属性还有要求。

com.adobe.crypto官方库的md5算法性能实在不敢恭维，算个10m的byteArray在我机子上跑了大概12s！我勒个去，这可怎么叫人活。随后找到个by.blooddy.crypto，提升了2个数量级的性能！
作者博客：http://va.lent.in/blog/2010/06/23/100x-times-faster-md5-and-more/
更新的博客：http://va.lent.in/blog/2010/07/10/more-on-faster-md5/
下载地址：http://www.blooddy.by/en/crypto/
我实际测试了下，10M的东西大概用了100ms左右，的确至少提升了100倍，作者此言非虚也！只是这个swc必须在flash cs5下编译才能成功，我用cs4调试半天老是报Main方法异常，郁闷很久才发现为什么。

在百度偶像内测的时候我得到了邀请码并且也试用了一阵子，目前偶像已进入beta阶段，我给我的一些坛子好友们也发了些邀请，过程中遇到几个细节上可以更完善的地方。于是乎一一述来。
先贴一曲：

如上图，外链的播放器这一点的确很让人享用，但是当歌名太长的时候，文字信息就会超出显示到外边。普通的桌面MP3播放器等，经常会有那种“文字滚动”的效果，即一行之类显示不完全，会让文字慢慢向左方滚动，如此展示完整。我在想偶像是否也可以用类似的或者其它的方式来解决这个问题呢？
再是外链链接方面，比如点击上图中的人名“西国の海妖”，应该是打开这位歌手的主页的，偶像确实也这样做了。但是遗憾的是，链接地址写的是相对地址，那么外链播放器这个链接也太……总之是个很低级的失误……
还有上传方面。我发现偶像在很多方面使用了flash，比如邀请注册的复制code那里，这与我们土豆很像，基本认定了这样一个准则：使用或浏览网站的用户一定是安装了必需版本的flash的。那么在上传方面，批量上传歌曲这种功能的出现就显得很人性化了。譬如从别的站点迁移过来的用户，有许多首歌要上传，一首首点岂不是要累死？以flash做个“高级上传”的页面功能，便可简化许多。
最后是歌词敏感过滤方面，比如我的lrc中如是填写：[01:18.99]上那繁盛帝国的荣耀与辉煌 转眼成荒芜坟场，会提示包含敏感词不能通过。仔细检查，原来是[01:18.99]这里有问题，难道是18.9被认为九月十八号比较敏感？类似的[02:08.96]也会报错，希望验证时对于lrc的[]时间部分可以忽略，毕竟一首歌那么多时间点，一一排查起来很恐怖。敏感提示的话最好也给个范围什么的，我用二分查找都很累……

想尝试使用FileReference的load方法来加载本地文件，从而在客户端预先进行一些处理，发现这个方法不是一般的耗时。假如选择了一个50M的文件，load就需要8s左右！更别说后续的处理操作了！
2s内能加载完毕的话，只有10m以下的小文件，可这怎么能够行？
而且我还没看到unload方法，adobe，你该改进改进了。

http://code.google.com/p/jase/
一段日子没怎么动了，惭愧惭愧。废了一天功夫，终于把redo和undo两个操作，与高亮逻辑关联了起来。具体做法就是将语法解析部分合并到命令链当中，与编辑器脱离了。这样每次编辑器内容发生改变的时候，直接执行命令链来保存改变，无需关心高亮逻辑，这些逻辑全部放在命令链中一同处理了。
当中遇到不少问题，还有以前的一些经验，比如：

侦听textfield的textInput事件时，倘若是手动修改textfield的text，是不会触发的，这点需要相当注意。
ie输入回车时是\r\n，而其它为\n，但是到了textfield里面又会自动将\n替换成\r，这个地方非常迷惑人！在做命令链时保存的内容尤为恼人，必须对所有的内容检测一遍，删掉\r\n，将\r替换成\n。
resize事件放到flash内部了，以前是通过js侦听window的resize，这样需要经过ExternalInterface的中转，效率太低，还需要外部嵌个div之类的。现在直接侦听stage的resize，好很多。
找人重做了图标，怕openoffice说我侵权。
正在加新语种。

这里可以试用svn的每次更新版本：
http://jase.googlecode.com/svn/trunk/jase1/bin/index.html

前阵子adobe和乔布斯大战，我作为as的拥护者，自然会导向adobe一方，不过今天发现乔布斯的一些抨击倒并不是空穴来风。
经常出现的那种js切换图片效果，如果变成js切换flash的话，自然也没什么大不了。切换图片时要么是几张图片轮播，要么是直接更改图片的href；切换flash时要么时call一个flash的侦听方法，要么是直接重写这一段html代码。
在第2种方法的情况下，明显能感觉出来几种浏览器的区别，无论是老的flash player也好、还是新的10.1也好，皆是。这里面google不愧和adobe合作，chrome来回切换丝毫没有问题；firefox很偶尔才会在切换时出现问题；而ie则太频繁了。猜测这也和chrome单进程的模型有关，这样切换时上一个遗留的flash不会造成内存泄漏。

adobe昨天公布的rc4，咱就迫不及待地用了，结果发现一个bug，这个在rc2中没有。
flash.net.NetStream，在使用seek(offset:Number)进行跳转后立刻togglePause()来暂停流（假设当前状态是播放），读取流的time属性并没有更新到offset。在rc2中确实更新正确了。