空门 的个人资料Gateway to nowhere照片日志列表更多  |  工具 帮助 |
|
2008/9/30 收了台 HP 2710p 样机
我承认自己对带 Wacom Digitizer 的设备抵抗力很差，但是 2710p 同时也是一个抗体，让我对以下设备产生了抵抗力。由于是台样机，几乎是新机的一半，我的罪恶感得到了补偿。2710p 在很多指标上都劣于以下设备（毕竟所谓疫苗，不过就是杀伤力较低的病原体罢了），但是我很满意。
Fujitsu T2010 Fujitsu T5010
HP 2730p iRex Digital Reader Series
iRex iLiad Series Wacom Cintiq 12WX 2008/9/14 Chrome 的渲染引擎和脚本引擎是并行处理的 今天把游戏引擎桢率限制去掉了，IE和FF在低负荷情况下，速度趋向于刷新率（60Hz），在高负荷情况下 IE 表现比 FF 好一些。但是 Chrome 能跑到 500 fps 上下，把整个系统的资源都抢占光了。当页面切换到后台的时候，FF和IE 都会把大部分资源释放出来，而 Chrome 会让整个操作系统响应变慢。由此可见，Chrome 的脚本引擎和渲染引擎是解耦的，只有这样它才能超越刷新率，并且在没有实际的渲染需求时抢占资源。
Chrome 的脚本引擎的确比较强大，但是对于游戏，通常瓶颈在于渲染。 2008/9/13 Chrome 的渲染能力不过如此Chrome 的兼容性不错，以前写的那套支持 Firefox 的游戏引擎能跑起来。唯一的麻烦是 Chrome 的安全性，XHTMLRequest + Window.eval 得到的变量被扔到一个特殊的名字空间。Chrome 积极地抢占系统资源，比 IE7/FF2/FF3 消耗更多的 CPU。更要命的是，Chrome 的渲染似乎未经优化，无论 Viewport 多大都占用差不多的资源。其他浏览器在不可见或最小化时，由于没有渲染负担，占用的资源都非常少，而 Chrome 则仍然占用相同的资源。这也可能是 Chrome 的设计思路造成的，毕竟大部分 Web 都是静态的，不像游戏引擎这样不断地操作图层。Chrome 很可能通过这样积极的渲染策略来提高响应速度，不过未免代价过大了些。 这个游戏渲染引擎是固定帧率的，每一帧都涉及复杂的脚本运算，但是最消耗资源的还是图像渲染。某些人可能会认为应该不限制帧率，以极限的帧率来判断高下。遗憾的是，实际的 Web Game 不追求帧率，当脚本消耗过多的处理器资源之后，用户界面的响应速度将会下降，影响用户体验，更别说大部分 Web Game 的用户都是三心二意的“Ligher User”。不过，为了满足这部分人的猎奇心理，我会设计新的测试。 Chrome 也许在某些场景下有优势，但是它并不适于游戏引擎一类不断渲染的应用。不过冬天快到了，Chrome 一定会为用户带来更多的温暖。 从上到下：Chrome、IE7、FF2，机器是一部 Fujitsu T4020,2G Ram |
|
|
