主题：【原创】漫谈浏览器大战 -- （构架篇） -- Highway
家园 【原创】漫谈浏览器大战 -- （构架篇） 最近工作之余稍有闲暇，于是就跟踪了一下最近IT方面的热点新闻。感觉着现在最火爆的两个战场就是手机OS和新一代的浏览器了。可惜我于手机知之甚少，只好避开这个话题谈谈浏览器了。
其实就浏览器而言，我也是业余，也就是自己在家里的PC上鼓捣几下，再结合一点专业上的common sense，如是而已。
浏览器这个领域原先是Netscape Navigator的天下（大家还记着吗），后来微软看着Netscape一夜蹿红怒不可遏，调兵遣将推出免费的IE。经过几个回合的较量，Navigator不敌IE，落草成了寇。再后呢，IE一统天下，市场份额超过了90%。一旦垄断形成，微软就再也没有前进的动力了。所以在很长的一段时间里浏览器这个领域基本上是死水一潭，没有任何创新。
真正意义上打响反IE第一枪的应该算是Firefox了，自推出以后不断的攻城略地从IE的手里抢市场。从技术上看，Firefox还是有一定建树的。首先文件很小，下载和安装都很快。另外，程序质量很高，比当时的IE更快捷更安全。还有，Firefox上的Add-on非常丰富，极大的增强和扩展了Firefox的功能。最后还应该指出的是Firefox支持其他OS，比如说Linux。
眼看着浏览器市场从一手遮天就演变到两强争霸了。没想到Google又半路杀出，非要来个Threesome。现在呢，除了这三巨头抢镜以外，苹果的Sarafi和Opera也搅了进来要分一杯羹。所以最近一段时间每个把星期就有一款浏览器推出新版本，并都会大言不惭的宣布是“天下第一快”。
外链图片需谨慎，可能会被源头改如果仔细一点看的话，就会发现这下一代浏览器争夺的主战场有三个
1）浏览器平台的构架
2）JavaScript虚拟机
3）图形图像的硬件加速
这第一篇呢，就说说新一代浏览器在结构方面的变化。（由于时间有限，所以只能就最有代表性的IE, FF和Chrome来说了，其他浏览器就不赘述了）
新一代的浏览器，清一色的采用了所谓的多进程构架（Multi-process Architecture）。网上的朋友们都常说是Google的Chrome领风气之先。但事实上呢，IE8的Beta版是最早采用这一构架上市的浏览器，从时间上看比Chrome还要早一些。所以呢Chrome首创这一构架的说法有些谬赞了。
有人会问了，怎么一下子大家都玩“多进程构架”了，早干嘛去了？原先的单进程构架怎么了？
早先的浏览器呢，都算是一个“程序”，所以都是传统的“单进程多线程”设计。也就是从任务管理器上看，只有一个进程（当然你可以启动多个浏览器了搞出来多个进程，那不是我们要讨论的问题）。浏览器内部呢，有很多的线程（thread），它们各司其职一同完成复杂的任务。这种设计线路中规中矩，程序开销小，效率高，没有什么不对的地方。
问题出在了“人民群众日益提高的文化物质要求”上。现在的浏览器已经不是一个传统意义上的“程序”了，已经演化成了一个“平台”。浏览器上搭载了无穷多的add-on，plug-in等等。人民群众要在浏览器上看新闻，听广播，点高清视频，玩3D游戏。。。
除了浏览器的任务变得复杂以外，人们使用浏览器的习惯也变了很多。浏览器上开十个八个Tab同时光顾数家网站已经是家常便饭，并且可能浏览器开了就不带关的，除非是出了问题。
开发浏览器的程序员们都渐渐的认识到，面对这样的任务和要求，原先的单进程构架已经不再适用了。原因很简单。因为单进程构架所以的东西都在一个进程里运行，一个地方出问题可能就会使整个浏览器全部歇菜。浏览器Vendor不管多么严格的控制程序质量，多么苦心积虑的进行测试，还是不能解决这一问题。因为浏览器面对的一个“Open ended world”，你永远无法控制第三方的add-on或是plug-in。这些程序如果出了问题，马上就会波及浏览器。
于是乎，多进程的构架就成为了不二之选。说到底，这种构架的核心就是把浏览器的各大功能块分开，运行在各自的进程里面。一个地方出了问题只会是局部的影响，不会造成整个系统的崩溃。现在的操作系统（Windows, Linux, Mac OS）中各个进程都运行在“保护模式”中，一个进程出了问题操作系统会将其的危害控制在该进程之内，不会对其他进程造成影响。这是浏览器采用多进程构架的基本前提。
这种构架为什么以前不用呢？因为这种构架要比单一进程的那种程序复杂很多。多个进程间的通信要解决好，并且要把开销压缩到最小。就现在的技术水平而言，这个问题已不再是什么大问题了。另外，现在大多的计算机都装配有多个CPU（多核），内存也都比较大，多个线程一起运行的硬件资源也不再是一个制约因素了。
虽然在战略上各个公司所见略同，但是在战术实施上还是相差甚远的。Google的Chrome看起来似乎革命最彻底，FF好像只是现有技术的一点点改良，而微软的IE呢，则是另辟蹊径，又搞了一套。
先看最简单的Firefox.
FF把所有的东西还是留在了主进程内。所以当你启动FF的时候还只是一个进程。当进入到一个网站的时候，如果网站比较简单，那么FF自己就料理了，不会产生任何新的进程。如果这个网站要求Plug-in的支持，比如说Flash，那么FF就生成一个进程（叫做plugin-container.exe)，在这个进程里运行Plug-in。如果你又开一个Tab去了又一家网站并且这个网站也需要Flash，那么FF就会共用现有的这个plugin-container为两家网站的网页提供Flash服务。所以说呢，FF的进程数量很好计算，那就是一个主进程 + 零到多个个plugin-container。plugin-container的数量取决于运行的Plug-in的种类有多少。
"C:\Program Files (x86)\Mozilla Firefox 4.0 Beta 7\plugin-container.exe" --channel=2572.bd74660.1358250153 "C:\Windows\SysWOW64\Macromed\Flash\NPSWF32.dll" "Mozilla.Firefox.4.0b7" -omnijar C:\Program Files (x86)\Mozilla Firefox 4.0 Beta 7\omni.jar 2572 \\.\pipe\gecko-crash-server-pipe.2572 plugin
有趣的是如果你离开了或是关闭那些需要plug-in的网站，FF并不销毁plugin-container进程。这呢，算是程序设计中一个常见的手段，就是你一旦使用了某个功能的话，那么很可能你还会再次使用。所以呢，那个plugin-container就给你留着，下回来的时候就是现成的，省事儿不是。但是呢，这种设计也有问题，因为plugin-container的数量只增加不减少，对用户而言，FF的内存越占越多。最后不得不把它干掉从新再来。
好，再来看Chrome
Chrome的做法是一个主进程（称为浏览器进程，就是我们看到的东西），1到N个渲染进程（Renderer进程），0-N个Plug-in进程（多少种plug-in就需要多少个plug-in进程，这点和FF一样），0-N个add-on进程（如果你的Chrome有3个add-on，那么就会多出三个相应的线程），一些服务进程（比如新的GPU process, Rundll32进程）。
对细节感兴趣的朋友，可以用Chrome自带的Task Manager去看看Chrome工作时界面之下后台进程生生灭灭的过程，很有意思。Google的这款浏览器就像一个茶馆一样，门帘永远在哪儿（主进程），客人们（Renderer进程）进进出出换了一茬又一茬。
Chrome的这种设计有两个突出的优越性。一是浏览器职能划分的很细，每一个功能体都在自己的进程中，一个进程的问题影响只是局部性的。第二，由于Renderer进程不停的产生销毁，所以即使程序有memory leak或是memory fragmentation也不要紧，因为过不多久进程就走人了，新进程又会从头再来,一切都是崭新的。
有网上的大拿说，Google的进程模式是Per process per site，不是Per process per tab。其实这句话之对了一半。比说你你到西西河来，Chrome马上生成一个Renderer进程来负责这个网站的Render工作（包括JavaScript的运行）。你点击几个link多出几个Tab来，Chrome并没有多出新的进程来。看起来那些大拿的话是对的。但是如果你手工增加一个Tab并敲入西西河的地址，只时候Chrome就会忘记已有的这个西西河Renderer进程，而重新在来一个（见下图）。
外链图片需谨慎，可能会被源头改和FF不同的是，如果一种plug-in没人用的话，Chrome会保留它一会儿。如果过了这个时间段还是idle，那么Chrome就将它回收了，如果在保留期间有什么网站需要这种plug-in了，那么就延长它的寿命让它继续工作。
另外Chrome9.0 Beta版在运行Plug-in进程的时候，多了一个Rundll32进程.
C:\Windows\system32\rundll32.exe C:\Users\Somebody\AppData\Local\Google\Chrome\APPLIC~1\90597~1.19\gcswf32.dll,BrokerMain browser=chrome。
这个进程感觉是在主进程和plug-in进程间起什么沟通作用的，但现在的Chrome 8版本没这个东西。另外Chrome会不知在什么时候冒出一个叫做GPU process的进程来。感觉是用GPU来做硬件加速用的，但是并没感觉到任何的不同，它的激活机制我还没有搞清楚。所以这个还有待于进一步观察。
OK，最后来看IE
IE的进程结构比较不直观。从外观上看，有些像Chrome的Per process per site（和Chrome一样也不是那么严格）。但是呢，IE不把Plug-in或是Add-on拿出去。除了主进程以外就是Renderer进程了，只有两种类型，而不是Chrome那样的五种类型。这个Renderer进程除了html, CSS, JavaScript任务之外，Add-on和plug-in的程序也在其中。所以说是一个heavy-duty的Renderer。
和Chrome不同的一点是，IE并不是急于创建或是销毁Renderer进程，它试图重新利用他们。比如你当前是在西西河，如果你在address bar输入另外一个网站的地址离开西西河到别的网站的话，IE会重用当前这个Renderer进程。而Chrome呢，是重新为新的网站生成一个新的Renderer进程，然后马上销毁西西河的这个Renderer进程。
外链图片需谨慎，可能会被源头改看到这里大家肯定有些晕了，不禁会问“你罗哩叭嗦的说了半天，到底哪种方案最好？”
这个很难说了，要看情况。比如说现在正是2012年伦敦奥运会，你开了三个Tab同时看三场比赛（Tab可以扯到桌面上铺开来看）。一个是中国转播的乒乓球，一个是美国转播的篮球，还有一个英国转播的足球。每个网页上呢是Flash转播的高清视频，另外还有HTML5技术提供的网友实时评论和场外花絮等等。
比方说，英国方面转播的足球出了问题，造成了Flash崩溃。那么用FF的用户和Chrome一样，什么图像都没了（因为Flash进程是共用的）。但是三场球的实时评论和场外花絮还能看得到。IE用户呢，情况不太一样，乒乓球和篮球还能看道视频，实时评论和场外花絮也完全正常，但是足球那个TAB就全歇菜了。
再比方说，美国网站HTML5提供的场外花絮部分出了问题，那么FF用户最惨，整个FF歇菜了，什么都没了。Chrome和IE的用户一样，乒乓球和足球还看着很好的，只不过是篮球那个Tab宕掉了。因为FF是用主进程来处理HTML5的，Chrome和IE都是独立的Renderer进程处理HTML5，出了问题之影响那一个具体的Process，别的Tab一点没事儿。
就我个人而言，有这么几点看法
1）FF的保护机理太过简单了。主线程任务太重，那里面一出问题整个浏览器就宕了。另外，Plug-in process重来不回收也是一个问题。
2)Chrome的进程显然太多了。如果你装了七八个个Add-on，再去几个网站的话，那么整个进程数可能就是十好几个了。对于那些内存少并且less powerful的机器可能就会是一个问题了。不知道在手机平台上Chrome浏览器是不是也用的同样的策略。
3）IE的想法不错，想把进程数量压缩在一个适当的范围内，不给OS太多麻烦。但是不把plug-in和add-on从Renderer进程分离出去，就每个Tab而言，保护程度和可靠性就自然下降了。在实践中的具体效果还有待于检验。
三种浏览器的新一代Beta版本我都用过，似乎Chrome给end-user的感觉最好。那么多进程间的通讯效果很好，进程不停的生成和销毁也没有任何停顿的感觉，界面上始终很流畅，很少有滞后感。（Chrome的程序员们本来开始是要用微软的COM技术来进行进程间通讯的，但发现COM不能满足他们对Async通讯的要求，于是就改用named pipe。虽然麻烦了一点，但看起来效果很不错。不过呢，在Linux平台上，又变成了Socket，不知道有什么原因。）
==============================================
待续。。。
本帖一共被 2 帖 引用 (帖内工具实现)家园 热门社交游戏厂商Zynga收购浏览器开发商Flock Zynga是当下的网上新贵（新贵的定义是成立时间小于10年)之一，其它新贵包括FACEBOOK, TWITTER,GROUPON.
家园 不是我不明白，这世界变化快啊！ 这两天CES上各家厂商疯了一般的推新品，眼都看花了。感觉这下一代的浪潮有这么几个热点
1）Smart Phone竞争会更加白热化。基本上是iPhone vs Android。iPhone吃利润忙着数钱，Android吃市场狂抢market share.
2）Tablet大战即将揭幕。和手机一样，还是苹果和Google挑头厮杀。微软，RIM等等敲敲边鼓，也想搅和进来。
3) 3D视频和HD on-demand streaming向广大消费者掩杀过来。
4）ARM体系的低能耗芯片向个人计算设备全面渗透，PC也不再是x86专美的世界了。另一方面呢，Intel和AMD也想向移动设备发动绝地反击。
家园 【原创】乱弹浏览器大战（1.2.3......） 乱弹浏览器大战（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很多都做不到。
通宝推：ustcat,捷克,家园 写的很好，可惜我无法通宝推荐 好像要“乐善”450以上才行，所以就先欠你一个吧。
Chrome有很多Tricks给用户以快的感觉，原则上很简单，就是prefetch，当一个页面载入的时候，它分析里面的内容然后就在后台给你先干起来。但我觉有时候这可能会是一个问题。比如我用手机去一个网页（比方说里面嵌了10个Flash Video）,Chrome会Prefetch这些Video。手机很多计划是计流量的，也就是说我在页面上停留了一会儿（比如说看了看新闻），二十分钟后我的流量可能已经快到顶了。
家园 你找到手机用户的痛点了。 钱是一个方面（流量限制，部分时间可以WIFI替代），UX是另一个方面，关键是这样做的无谓能耗（数据下载的能耗很大，不论是3G,2.5G还是WIFI）。当手机的电池就剩两格的，手机上网就 TOTALLY Fxxk AWAY --- 总要留着点电池给电话，短信，Email，。。。
家园 【原创】关于构架，补充一点 IE从很早开始，就以一个ActiveX Control的形式提供给程序员，你可以在你的程序里很容易的集成IE，或是根据你自己的需求定制一个IE浏览器。很早以前我和铁手开玩笑，专门写了一个小程序用来灌水。当时好像铁手限制“口水帖”，不满200字的帖子不接受。我的小程序呢就是检查一下回帖的字数，不够的话瞎胡添点废话凑够200字。
如果你在程序中使用WebBrowser Control，当前机器中安装的IE就会被自动载入。下面两个图就是我刚写的一个程序运行在两台机器上的结果。一个是IE8,一个是IE9。后者呢，拥有一切最新浏览器的功能（新的JavaScript Engine, HTML5硬件加速等等）
外链图片需谨慎，可能会被源头改
外链图片需谨慎，可能会被源头改有朋友一定好奇了，IE8和IE9都是多进程构架，那你这程序中使用了这样的Control，启动后会有几个进程呢？
答案是一个。为什么呢？这就算是一个思考题留给大家吧！
家园 【原创】漫谈浏览器大战 -- （硬件加速篇） 对人民群众来说，硬件加速这个词听着有些别扭，有见买硬件来减速的吗？
硬件加速这是一句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篇）
=======================================