关于Flash Player的“跑道/切片模型”

http://swfever.com/?p=1076

在早前的一篇文章中我曾经提到过：“Flash Player的“跑道”模型最早由Ted Patrick提出，而Sean Christmann将这个理论进一步扩展成了“切片”模型，但是我对这个模型的结论抱有很大的质疑，这个模型和我的实验结果有很大的出入，有时间我会专门来撰写文章和大家分享讨论。”

正巧最近天地会论坛上有一篇针对切片模型的翻译，我借机将我的质疑提出来，并引发了一些讨论。我的质疑主要针对于原文中的以下论述：

Additionally,if you choose,you can render to the screen sooner then the compiled framerate by calling updateAfterEvent(),but only within a Mouse,Timer,or Keyboard event handler. In this instance though,the Marshal will consider that the end of the frame and start a new frame on the next slice.

根据我的实验结果，调用updateAfterEvent()会触发RENDER事件并进行实际的重绘，但并不会造成“当前帧结束并开始下一帧”。也就是说，你可以在同一帧之内，多次触发RENDER事件及其关联的处理函数，并对对屏幕进行多次重绘，并不会对帧进行“打断”。进一步来说，原文中的模型所基于“用户事件代码可以执行多次，而渲染事件代码和真正的渲染操作只在最后一个Slice执行”的假设并不成立，或者说，该假设只能说明某种情况，而不绝对成立。

为此，我特地咨询了我的同事，也是“跑道”模型的最初提出者Ted。他非常迅速的给了我回复，内容如下：

Yes you can call updateAfterEvent over and over between standard renders. You basically inject a partial render in the code execution side of the racetrack and elongate it.

翻译如下：

是的，你可以在每次标准RENDER（即原文中的Last slice’s render）之间调用多次updateAfterEvent（并进行重绘），相当于你在跑道一圈中代码执行的阶段”注入”了部分渲染过程并延长了整个跑道。

至此，我想这一问题应该是比较清晰了，跑道模型并不绝对，由于updateAfterEvent和Flash Player内部强制重绘需求的存在，我们可以在一帧的用户代码时间插入渲染事件代码，并进行多次重绘。也就是说，在一帧中，用户代码并不总是先于渲染代码而执行，它们是有可能交替进行的。

另外，Ted还提到：

I would love to see AS have full render control as a playermode in FP11. If set there are no automatic renders and the developer must call render for all visual changes to occur.

翻译：

其实我很希望看到Flash Player 11可以在某种模式下给开发者完整的渲染控制。在这种情况下开发者必须主动调用API来实现屏幕重绘。

的确，如果能够实现完整的渲染控制，将会给开发者对性能优化带来更大的提升空间～。

This entry was posted on Wednesday,February 24th,2010 at 1:09 pm and is filed under?ActionScript,Flash Player.