Time between enterFrame events

[Bob_Flesch]

Thanks for looking

I am trying to understand why the flash player in a browser takes so long to return between frames.

I have my target frame rate at 60 fps.

When I enter the frame, I do what I need to do (GPU and CPU) tasks. That takes about 5 ms.

Upon leaving the frame I mark the time I left, then upon getting the next enterFrame event, I record the current time.

What I notice is the time between frameRate events is longer then it should be.

For example from my log.

enterFrame - render: 3  timeUpdate: 2  total time: 5  time to get back to app: 20  desired frame rate: 60

enterFrame - render: 4  timeUpdate: 1  total time: 5  time to get back to app: 19  desired frame rate: 60

enterFrame - render: 4  timeUpdate: 1  total time: 5  time to get back to app: 20  desired frame rate: 60

enterFrame - render: 4  timeUpdate: 1  total time: 5  time to get back to app: 16  desired frame rate: 60

so my effective frame rate is the total time I take plus the amount of time to get back to app with the next enterFrame event.

5 + 19 = 24 ms ~ 41 fps

What I would hope for it 16.77 ms minus my last time it took to update and render the last frame.

Any clues on why it is taking so long?

Things to correct this?

This seems to be a relatively recent problem.

I am running on Window 10, in version 23.0.0.162 in Firefox version 49.0.2 on a VirtualReality rated PC.

bob

[kglad]

this is an excerpt from (Flash Game Development: In a Social, Mobile and 3D World)

Everything done by the Flash player uses CPU/GPU.  That means everything displayed in your game and every bit of code that executes in your game requires processing by the CPU/GPU.  In addition, if your swf's frame rate is greater than zero, even when there is nothing on-stage and no code executing, your game still uses CPU/GPU. 

That is, if you open Flash Pro, save your fla and publish your swf, that game still uses the CPU/GPU when it runs.  Even that empty stage swf with no code is repeatedly using the CPU/GPU.

For example, if your game's frame rate is 24, then 24 times per second (if the host computer/device can cope with that frame rate), the Flash Player does the following

1. It checks for any events completed from the previous 1/24 second.

2. Then it executes the listener function code, if there is any, for those events.

3. Then if you have code on a frame that was just entered, that code will execute.

4. Then it dispatches the Event.ENTER_FRAME event to all your listeners for that event.

5. Then the display is rendered.

And, that is not all the Flash Player has to do.  If you create an Object (i.e., anything) at any time, the Flash Player has to allocate memory for that object and it has to store that object reference and its value, if any was assigned when it was created.  If there is no currently available memory Flash allocates more memory.

But, that's not all the Flash Player has to do. Before it allocates new memory, it checks for objects that can be removed from memory.  If it finds any, it marks them for removal and, on a subsequent clock cycle, it clears that part of memory. 

And the best (or worst) is yet to come.  The marking of objects for removal is itself a dizzying multi-step process that involves checking each and every object that exists and then counting all the references to each and every existing object.  All objects with zero references are marked for removing (sweeping in Flash parlance) and (eventually) cleared from memory.

Other than steps 3 (game code) and 5 (the graphics displayed), most of us do not consider the other steps that impact our game's performance.  However, the time required to complete all five steps determine if your game runs smoothly or not.  If the time required to complete all five steps is greater than 1/fps second, a frame will remain on-stage longer than 1/fps second. Put a few of those frames together back-to-back and your game appears to stutter.

There are two main points that I want to convey in this section:

1.  There is a lot going on in even the most basic Flash game and all of it uses CPU/GPU.

2.  Memory management has an impact, not just on memory, but also on CPU/GPU.

After seeing what the Flash player does many times per second, it is amazing that, for many game players, there are no noticeable performance problems with most Flash games.  However, an increasing number of computer users, using relatively weak computing devices like mobiles, are having problems with Flash games (and everything else Flash).

[Bob_Flesch]

Thanks for the reply, but not quite what I was looking for.

I have been a game dev for many years, both in C++ directX and Flash.

So not only do I have a good feel, I can back up everything with data from Adobe scout.

Still looking for how I can reduce that between frame event time.

[kglad]

i have an entire chapter in that book about optimizing swf performance.  for most situations using cacheAsBitmap and/or cacheAsBitmapMatrix gives the most benefit with least effort, but they have to be used appropriately.

here's another except with more info if the above is less than sufficient:

Optimization Techniques

Unfortunately, I know of no completely satisfactory way to organize this information. In what follows, I discuss memory management first with sub-topics listed in alphabetical order. Then I discuss CPU/GPU management with sub-topics listed in alphabetical order.

That may seem logical but there are, at least, two problems with that organization.

1. I do not believe it is the most helpful way to organize this information.
2. Memory management affects CPU/GPU usage, so everything in the Memory Management section could also be listed in the CPU/GPU section.

Anyway, I am going to also list the information two other ways, from easiest to hardest to implement and from greatest to least benefit.

Both of those later listings are subjective and are dependent on developer experience and capabilities, as well as, the test situation and test environment. I very much doubt there would be a consensus on ordering of these lists.  Nevertheless, I think they still are worthwhile.

Easiest to Hardest to Implement

1. Do not use Filters.
2. Always use reverse for-loops and avoid do-loops and avoid while-loops.
3. Explicitly stop Timers to ready them for gc (garbage collection).
4. Use weak event listeners and remove listeners.
5. Strictly type variables whenever possible.
6. Explicitly disable mouse interactivity when mouse interactivity not needed.
7. Replace dispatchEvents with callback functions whenever possible.
8. Stop Sounds to enable Sounds and SoundChannels to be gc'd.
9. Use the most basic DisplayObject needed.
10. Always use cacheAsBitmap and cacheAsBitmapMatrix with air apps (i.e., mobile devices).
11. Reuse Objects whenever possible.
12. Event.ENTER_FRAME loops: Use different listeners and different listener functions applied to as few DisplayObjects as possible.
13. Pool Objects instead of creating and gc'ing Objects.
14. Use partial blitting.
15. Use stage blitting.
16. Use Stage3D.

Greatest to Least Benefit

1. Use stage blitting (if there is enough system memory).
2. Use Stage3D.
3. Use partial blitting.
4. Use cacheAsBitmap and cacheAsBitmapMatrix with mobile devices.
5. Explicitly disable mouse interactivity when mouse interactivity not needed.
6. Do not use Filters.
7. Use the most basic DisplayObject needed.
8. Reuse Objects whenever possible.
9. Event.ENTER_FRAME loops: Use different listeners and different listener functions applied to as few DisplayObjects as possible.
10. Use reverse for-loops and avoid do-loops and while-loops.
11. Pool Objects instead of creating and gc'ing Objects.
12. Strictly type variables whenever possible.
13. Use weak event listeners and remove listeners.
14. Replace dispatchEvents with callback functions whenever possible.
15. Explicitly stop Timers to ready for gc.

  16. Stop Sounds to enable Sounds and SoundChannels to be gc'd.

[Bob_Flesch · Accepted solution]

Good advice, but again this has all been done already.

I did find that even if I set the frame rate to 1000 (which adobe says I can).

The frame rate from stage.framerate is 232.

And it still takes 20+ ms for the next frame, disappointing.

[kglad]

i think the best you can do is a frame rate of 120 and about 8ms between enterframe calls.

[Bob_Flesch]

I can crank up the frame rate and get the inter frame time down, but what I would really like to do is immeadiatly return from the enterframe, but kick off the update process. So that the enterframe handler only take 0 second, and I get a steady 14-18 ms per frame.

I am going to try putting what was my main into a worker which should run independently.