为什么在刷新Flash中的屏幕之前出现EnterFrame

Question

假设我们在Flash中有1 fps的动画，其中每个帧都有一个运行100 ms的脚本。据我所知，在Flash动画的工作原理如下：

0ms: Begin executing Frame 1's frame script 
100ms: Finish executing Frame 1's frame script 
1000ms: Begin rendering Frame 1's content and frame-script output 
1050ms: Finish rendering Frame 1's content and frame-script output 

1051ms: Begin executing Frame 2's frame script 
1151ms: Finish executing Frame 2's frame script 
2000ms: Begin rendering Frame 2's content and frame-script output 
2050ms: Finish rendering Frame 2's content and frame-script output 

2051ms: Begin executing Frame 3's frame script 
2151ms: Finish executing Frame 3's frame script 
3000ms: Begin rendering Frame 3's content and frame-script output 
3050ms: Finish rendering Frame 3's content and frame-script output 
... 

这个工作流程是合乎逻辑的，作为帧脚本正在执行在等待下一个屏幕更新。即使脚本需要长达1000ms的执行时间，渲染也不会延迟，并且仍然会达到1fps。

但是！当从AS3内部编程动画时，人们经常使用ENTER_FRAME事件，在之前发生下一次屏幕更新。然后，如果我们有需要1000ms的指令来执行，工作流程如下：

0ms: do nothing (waste time!) 
1000ms: begin executing instructions in ENTER_FRAME 
2000ms: finish executing instructions in ENTER_FRAME 
2001ms: Begin rendering Frame 1's content and ENTER_FRAME output 
2051ms: Finish rendering Frame 1's content and ENTER_FRAME output 

2051ms: do nothing (waste time!), as we have to wait 1000ms from last rendering to current 
3000ms: begin executing instructions in ENTER_FRAME (1000ms after last rendering) 
4000ms: finish executing instructions in ENTER_FRAME 
4001ms: Begin rendering Frame 2's content and ENTER_FRAME output 
4051ms: Finish rendering Frame 2's content and ENTER_FRAME output 

4051ms: do nothing (waste time!), as we have to wait 1000ms from last rendering to current 
5000ms: begin executing instructions in ENTER_FRAME (1000ms after last rendering) 
6000ms: finish executing instructions in ENTER_FRAME 
6001ms: Begin rendering Frame 2's content and ENTER_FRAME output 
6051ms: Finish rendering Frame 2's content and ENTER_FRAME output 
... 

因此，我们有0.5 fps的，而不是1个FPS！由于ENTER_FRAME发生之前渲染现场，延迟来了。对我来说，如果ENTER_FRAME发生之后渲染场景，为下一帧渲染做好准备。

这是一个玩具的例子，在现实世界中渲染不会发生在那个完美的时间表，但逻辑是相同的。当有15毫秒的代码执行每一帧（完全正常的情况），60 fps将变成30 fps ...

...或不是？我说的是否有缺陷？

Answer 1

输入框架是生命周期的开始。

Display object lifecycle：

1. 事件类型的事件Event.ENTER_FRAME分派的子显示对象执行
2. 事件从孩子显示分派的事件类型Event.ADDED的对象
4. 构造代码事件类型的事件210从孩子显示分派对象
5. 事件的事件类型Event.FRAME_CONSTRUCTED的分派
6. MovieClip的帧动作的执行
7. 儿童影片剪辑的帧动作将被执行
8. 事件的事件类型Event.EXIT_FRAME的分派的事件类型Event.RENDER的
9. 事件派出
10. 事件类型Event.REMOVED事件类别从儿童展示对象派发
11. 事件前夕nt类型Event.REMOVED_FROM_STAGE从儿童显示对象派发

你所描述的通常被称为弹性跑道，其中大量代码执行可能会延迟帧渲染。