主题：【原创】漫谈浏览器大战 -- （构架篇） -- Highway
对人民群众来说，硬件加速这个词听着有些别扭，有见买硬件来减速的吗？
硬件加速这是一句IT道上的黑话，意思就是让某些专用芯片来完成一些特定的操作，而不是由CPU运行软件来完成这些任务。以前曾经有很多专用的处理器，比如浮点数协处理器，VCD解压卡等等。但是那些工作量对现代的CPU来说都是小菜一碟，不用也罢。所以现在人们说到硬件加速，其实就是指用Video Card加速。也就是给CPU松绑，给GPU上套（套上马车的套）。
有了说了，把CPU的工作仍给GPU，工作量并没有减少，换汤不换药，有什么好处？
寸有所长，尺有所短。GPU在处理某些任务上比CPU要强得多（很多情况下强几十甚至上百倍），不光是性能上强，而且在能耗上也很有优势。现在的新一代移动芯片，CPU功能未必有多强大，但大多的图像图形处理都交给了GPU，所以很多轻巧的手机，平板电脑都可以轻松回放1080p的高清图像。如果就靠CPU来做，那么一个INTEL的Core 2 Duo都会类的臭死。
既然GPU那么牛，干脆把CPU废了，给GPU扶正不行吗？
不行。因为GPU虽然干某些事情很牛，但毕竟不是通用型处理器，很多事情处理不了。软件工业发展了这么多年的家当能在GPU上跑的还毕竟是个零头。现在搞GPU的厂商（ATI, nVidia）都想拓宽GPU的应用，搞所谓的通用型GPU(GPGPU),但是这件事并不容易，我看离成熟还有些日子。对GPGPU感兴趣的朋友，不妨看看我这篇老帖子 -- GPU作超级计算，有那么美好吗?
所以现在所说的硬件加速，就是尽可能的将一切可以扔给GPU的活都甩给GPU,剩下的就只好还是由CPU来做了。这件事听起来容易做起来难，但是呢，一旦做成了性能有质的飞跃，诱惑还是很大的。新一代的浏览器对图像图形要求极高，并且3D可能马上就要全面在网上展开，如何解决好这一新的问题成了各个浏览器厂商的当务之急。
有人说了，其实浏览器根本不需要操这个心，新一代的高清视频和3D图形交给对应的Plug-in不就行了吗？比如说Flash或是SVG。事实上，Plug-in的厂商也在兜售这个概念，Flash 10.2 Beta和刚刚发布的Silverlight 5.0都支持硬件加速的高清视频回放。
但是，plug-in终究不是浏览器本身，新一代的浏览器都想甩掉plug-in直接支持HTML5里面的那些新的TAG，比如video, audio， canvas等等。
就硬件加速这个环节而言，个人以为现在是IE9做的最好。用他们的话就是IE9是“全程硬加速(Full HA)”，而其他浏览器呢都是“局部硬加速（Partial HA）”。他们的口号是“IE9 -- Surf on Metal with GPU Powered HTML5”。
IE9提供了一两个网站，Test Drive Site Map,大家可以自己试试看。我试过IE9， FF4，Chrome8.0， 9.0 Beta和10.0Canary buiild，感觉还是IE最好，无论是图像操作，3D SVG，还是文字缩放，IE9表现的都很好。Chrome和FF表现参差不齐，有的和IE很相近，有的则惨不忍睹。
有人说了，这是微软自己提供的网站，选的那些例子都是IE9擅长的，所以没什么参考意义。这话呢，有一定道理，厂家自己的测试总是给自己脸上贴金的。不过呢，这些测试都是很基本的HTML5操作，很透明的，玩“猫腻”的机会有限。所以不妨先作为一个benchmark用着。
为什么微软能在这个领域跑在前面呢，我认为有两个主要原因。
1）微软的DirectX搞了快15年了，现在都到11.0版本了。他不仅搞API给游戏厂商用，他自己也搞3D游戏。所以就图形图像加速这一头，微软的功力别家还真比不了。从Vista开始，微软翻新了显示驱动这一子系统，为应用程序使用硬件加速奠定了基础。不用说浏览器了，就是用。NET开发的程序都能用上这一功能。比如你用.NET写WPF程序,都是基于DirectX之上的。再比方说，用Media Player回放高清视频，CPU占用率真的很低，更改对比亮度什么的也不影响CPU usage。如果用第三方的播放器，比如大名鼎鼎的VLC，CPU占用率就上去了，如果调整一下contrast，CPU就更忙了。
2）微软的IE9没有跨平台这一顾虑，它甚至连WindowsXP都不支持，所以它可以完全按照Windows Vista/7的图形系统来写。如果有什么不方便的地方，连OS的文件都可以更新。IE9是我试用的浏览器中唯一需要重启系统的。Chrome和FF不同，他们要考虑其他平台，通常呢，一个抽象层就要引入（abstraction layers），这样性能就不可避免的要有折扣。如果想要让各个平台上的版本都有相近的表现，那么可能技术上就更困难一些。因为在Windows上用DirectX实现的东西可能在Linux就没那么个API，可能需要多个OpenGL的调用才能带到同样的目的。当年我曾解释过Java 1.4以后的数学运算为什么比1.3以前还要慢的秘密（参考拙作Java Fantasy 漫谈），基本上就是“跨平台”拖了后腿。显然的，FF和Chrome制肘的地方要比IE9多。
IE9的硬件加速功能，如下图所示，三个主要的阶段IE9都有动作。
1. 内容渲染段（Content Rendering Phase）. IE9使用Windows的Direct2D和DirectWrite子系统，所以呢，文字和矢量图形的现实都很平滑。这个阶段使用GPU，对HTML的一些最基本元素都有提升效果，比如文字，图像，背景和边框等等。
2. 页面组合段（Page Composition Phase）. IE9在这个阶段使用了微软自己的Direct3D，对于图像密集操作的那一类页面，性能有一个飞跃。大家可能看过IE9的一个DEMO，就是一个阵列浏览器的LOGO在屏幕上飞来飞去，有了GPU加速，CPU基本上不怎么出力，那一群图像已经在屏幕上舞的如痴如狂了。GPU的一个绝活就是飞快的现实bitmap图像，并且这些图像都在GPU自己的显存里面，再次显示的时候把显存的图像拿出来就成，怎能不快！
3. 桌面组合段（Desktop Composition Phase）。浏览器拼装好的页面，最后要交给Desktop Window Manager (DWM)来反映到屏幕上。IE9使用的是纯DirectX和DWM打交道，比起以前的DirectX和GDI+的混合模式要更直截了当，GPU内存开销小，稳定性也更好，
当然了，我的这些结论都是基于现在Beta版本的，将来正式版本的情况还要到时候才能说。还有，这个HTML5是不是能成为下一代的标准还有待观察。所以呢，就这个话题我们可以以后再聊。现在就先告一段落了。
======================================
2.【原创】漫谈浏览器大战 -- （JavaScript篇）
=======================================
花一个。写的非常棒
IE从很早开始，就以一个ActiveX Control的形式提供给程序员，你可以在你的程序里很容易的集成IE，或是根据你自己的需求定制一个IE浏览器。很早以前我和铁手开玩笑，专门写了一个小程序用来灌水。当时好像铁手限制“口水帖”，不满200字的帖子不接受。我的小程序呢就是检查一下回帖的字数，不够的话瞎胡添点废话凑够200字。
如果你在程序中使用WebBrowser Control，当前机器中安装的IE就会被自动载入。下面两个图就是我刚写的一个程序运行在两台机器上的结果。一个是IE8,一个是IE9。后者呢，拥有一切最新浏览器的功能（新的JavaScript Engine, HTML5硬件加速等等）
有朋友一定好奇了，IE8和IE9都是多进程构架，那你这程序中使用了这样的Control，启动后会有几个进程呢？
答案是一个。为什么呢？这就算是一个思考题留给大家吧！
其实是很让人泪流满面的，微软好久没有这么牛的决策了
一方面开启了一个新战场
另一方面这个新战场恰好还是自己的强项
就怕这次还是反应太慢，等他ie9正式版出来，人家chrome的硬加速已经实用化了，那可真正才是大悲剧，大丧钟
不喜欢IE一副官方嘴脸，启动又巨慢，还是支持CHROME。
我现在只在UBUNTU下用CHROME，在WIN7下FF还是主力，CHROME加上扩展也用起来没能像FF那样趁手，主要是代理和鼠标手势这块的扩展跟不上。
当我发现微软其实是一家很了不起的公司的时候，微软已经没那么了不起了
firefox 3.6到好像支持的挺好，你那个64帧的测试用啥显卡跑的？
IE8不支持很多HTML5的TAG。
另外那个64帧不是我的成绩，我的显卡是GT430,帧数好像不到点60.
IBM也有过曾经，微软也会变成曾经，Google有一个也会变成曾经，最近见闻Google的工程师外逃到Fackbook，不知是否是个趋势
这里真正反映技术水平的东西不多，更多反映的是古狗的数据采集汇总能力。古狗的街景并不是真正的3D景观，而是古狗街景采集车从六个水平角度拍摄的街景图像拼接出来的一张360度全景图像。至于街道名称、商业店铺、公共设施等等，都属于数据采集汇总的范畴，没有多深的技术在里面。
古狗的Direction算法，在技术上确实不错，既快又准。这种路径算法本身是公开的，并不神秘，我以前也做过。但在实际应用中，算法受道路网数据量的限制很大，当数据量太大时，算法就会非常慢。像古狗这样的网络地图供应商，必须对算法进行优化，其办法无非是将道路网分层，然后用平行处理的方法对不同层次的道路网分别做路径计算，然后把结果汇总。如果我猜的不错的话，现在网上的几家大的网络地图供应商，采用的路径选择算法都是一样的，很可能都是购自同一个软件公司，所以它们的计算速度都差不多，就像它们的卫星图像都购自同一家卫星影像公司一样。计算的路径结果之所以会不同，是因为各自存储的道路网数据不同而已。
乱弹浏览器大战（1.2.3......）
1.如果说“最火爆的两个战场就是手机OS和新一代的浏览器了（楼主语）”，那么最最火爆的是什么？
没错，新一代的手机浏览器。这么说吧，如果手机(包括平板电脑)厂商没有一个TEAM（可大可小）专攻移动浏览器，这个手机相关厂商在业内的位置都算不上十分重要。这个名单包括：
A.浏览器技术公司：
Apple(Webkit项目拥有者,Safari浏览器和移动浏览器)
Google(Chromium项目拥有者, Chrome浏览器和Android移动浏览器),
MS(Trident引擎， IE浏览器和移动浏览器)
Mozila(Gecko项目拥有者, Firefox浏览器和Fennec移动浏览器)
Opera（Presto引擎，Opera浏览器，Opera Mini浏览器,Opera Mobile浏览器)
至于国内，有UCWEB和Maxthon。
B.手机厂商
HP（WebOS浏览器基于Webkit引擎）
RIM（基于Webkit引擎的浏览器，IRIS Team来自于收购的Torch Mobile company公司）
Nokia(Webkit On QT.另外收购过Novarra）
Motorola，HTC，Barnes & Noble（Nook Color），Amazon
C.手机芯片厂商
Qualcomm，MTK。（这些厂商的信息可以从他们的招聘广告推断，全是基于Webkit）。
2.由于开源项目，特别是Webkit项目和Chromium项目，发布一个商业浏览器或者拥有一个浏览器团队已经不再需要十分昂贵的成本。关键是拥有这样一个团队的目的和商业价值。从技术的角度看，除名单A中前5个公司拥有完整的浏览器技术，其它公司仅仅是利用名单A中前4个公司的技术方案,其技术难度按Apple ---》 Mozila ---》 MS ---》 Google的次序递减。因为Apple就是一个Webkit渲染引擎，浏览器开发团队必须自己实现浏览器框架,Mozila有完整的浏览器源码框架，MS有完整的浏览器及Trident引擎运行框架（shdovvw.dll与mshtml.dll，楼主的“浏览器”不过是通过COM调用了一下shdovvw.dll）。Chromium也是完整的浏览器源码，但是与Mozila比非常容易入门。使用Chromium或者Mozila项目都有有大量繁琐的文档替换工作，否则这个浏览器只能在私下里跑着玩。
处于二，三线的浏览器公司全面倒戈到Chromium已是潮流。北美有Flock(开始用Mozila方案)，国内有Maxthon（开始用MS的shdovvw.dll后来用mshtml.dll）。至于新来的开始就拿Chromium上手，北美有Rockmelt,国内有搜狐。
3.Webkit是渲染引擎的总体名称，也是这个渲染引擎与“浏览器”之间的API接口的名称。在C++的命名空间，渲染引擎用WebCore,API才用Webkit。
如果设计一个基于Webkit的浏览器，有下列问题必须考虑（简单起见，不包括PLUGIN, ADDON问题）。
a.虚拟图形屏幕的实现，供Webkit画网页。
b.向Webkit提供用户输入的鼠标与键盘事件。
c.提供Webkit请求的网络资源.(HTTP与https请求,HTM, CSS, JS, COOKIE...等资源)
d.不同OS上物理/虚拟图形屏幕的转换,物理设备与Webkit鼠标与键盘事件的转换。
e.Webkit请求到网络SOCKET的转换，网络资源本地缓存管理。
f.浏览器GUI的设计，菜单，TAB。
g.浏览器的进程与线程模型。
h.JS引擎的替换（可以不做，Webkit有预置JS引擎）。
4.Chromium的设计优先策略第一是安全，第二是UX（用户体验）.其多进程模型主要保证其安全性，其多线程模型才是保证用户体验的关键。多进程模型不仅耗用更多的内存，也耗用更多的CPU计算，比如一个鼠标/键盘事件要穿越4个线程，2个进程。
Chromium多线程模型保证了关键线程（如UI,网络，数据库，文件I/O）不被阻塞。很多地方不是Chromium真的快，而是Chromium显得快。
5.有名管道是Chromium进程交换数据最频繁的渠道（KB级别），但不是Chromium进程交换数据量最多的渠道。Chromium用进程共享内存交换屏幕图形数据（MB级别）。Chromium不用COM的原因主要是Chromium的设计目标是绿色安装（拷目录结构就可以了）。
6.Chromium并非喜欢PLUGIN运行在单独的进程，而是为了兼容旧的PLUGIN。Chromium喜欢PLUGIN运行在RENDER进程的沙箱内，不过目前的PLUGIN很多都做不到。
好像要“乐善”450以上才行，所以就先欠你一个吧。
Chrome有很多Tricks给用户以快的感觉，原则上很简单，就是prefetch，当一个页面载入的时候，它分析里面的内容然后就在后台给你先干起来。但我觉有时候这可能会是一个问题。比如我用手机去一个网页（比方说里面嵌了10个Flash Video）,Chrome会Prefetch这些Video。手机很多计划是计流量的，也就是说我在页面上停留了一会儿（比如说看了看新闻），二十分钟后我的流量可能已经快到顶了。
钱是一个方面（流量限制，部分时间可以WIFI替代），UX是另一个方面，关键是这样做的无谓能耗（数据下载的能耗很大，不论是3G,2.5G还是WIFI）。当手机的电池就剩两格的，手机上网就 TOTALLY Fxxk AWAY --- 总要留着点电池给电话，短信，Email，。。。
Zynga是当下的网上新贵（新贵的定义是成立时间小于10年)之一，其它新贵包括FACEBOOK, TWITTER,GROUPON.