What is a Frame and Frame Per Second?

Question

I'm new to the unity Editor, trying to understand Unity scripting.

What is frame? I can't tell from how it's used whether "frame" is a function, or a measure of time.

I see this term used in different ways:

• Update() is called every frame - Unity Document says

• Update() is called during a frame - Some People Says

• Update() is called once per frame - Some People Says

I'm confuse by these statements - what is true/false?

Is frame() a function?

Or is frame a unit of time?

And what is frames per second (fps)?

I've been trying to investigate using this code:

void Update ()
{
    CallThisOne();   // how many frame per second by default ex 60fps,30fps??
    CallThisTwo();   // how many frame per second by default ex 60fps,30fps??
}

void CallThisOne()
{
    Debug.Log("CallThisOne");
}

void CallThisTwo()
{
    Debug.Log("CallThisTwo");
}

Output:

Answer 1

Games inherited this term from animation, film, and video.

There, a "frame" is one still image in the sequence. By playing lots of frames in rapid succession, we create the illusion of motion.

See this strip of 35 mm film from the Museum of Obsolete Media. In it, we can see three consecutive frames of a Spider-Man movie.

The framerate of a piece of animation/film/video is a measure of how quickly we move from one frame to another. Common values you'll see are 24, 30, or 60 frames per second - that's where the "FPS" abbreviation comes from. In an animation running at 24 fps, 24 different frames (pictures) are displayed for each one second of playback time.

So, at a particular framerate, we can also think of one "frame" as a measure of time - say 1/24th of a second for a 24 fps animation.

All of this carries over to games - the difference is that we typically have to create each image a fraction of a second before it's displayed, rather than just playing back an already-existing image sequence. That includes both the actual work of drawing, and the work to update the internal state of the game - like the positions of the characters - so that we know what to draw.

In games we can say...

• A rendered frame is one complete image presented to the player's screen.

• By rendering and displaying new frames very quickly, games create the illusion of motion.

• The frame rate a game is running at is a measure of how many new frames it displays every second - so a 60 fps game is rendering and displaying 60 new images every second.

• A frame interval is the span of time between displaying two consecutive frames. For a game running at 60 fps, that's just over 16 milliseconds.

  You'll often hear game developers and players call this span of time "a frame" - like when a fighting game player says "this attack takes 5 frames to hit" what they mean is that 5 frame intervals pass between the time the player hits the attack button and when the attack actually does damage - leaving a potential window to interrupt or block the attack.

• We'll also sometimes loosely refer to all the work that the game has to do in order to prepare the next rendered frame as "a frame".

So we do use this word to mean a few different but related things. Generally it's pretty clear what's intended based on the context.

Let's dig into Unity's context to see how this applies.

The Unity game engine has a sequence of steps it goes through for each rendered frame it presents to the player's screen. I'll simplify a little here, but you can find the full breakdown in the documentation.

1. First, the engine reads the player's input since the last time it checked - things like keyboard key presses, mouse movements & clicks, gamepad buttons, sticks, and triggers, anything you can access via the Input class.

2. Next, the engine ticks forward the game's physics simulation. This involves running all active scripts' FixedUpdate() methods, then integrating movements using the physics engine, then calling any collision-handling methods like OnCollisionEnter() or OnTriggerStay().

   It repeats this trio of operations as many times as it needs to for the game simulation to catch up to the current time (up to a limit). So if the game has been running slow and a lot of time has passed since the last physics step, it might have to loop these several times to catch up. But if the game has been running very fast, it can sometimes skip the physics step entirely, because not enough time has passed for a new one.

3. Third, it calls all Update() methods on scripts.

4. Fourth, it updates any animations that are currently playing and applies IK fix-ups.

5. Then it runs any LateUpdate() methods on scripts, to do last-minute fix-ups that need to react to work that happened earlier in the frame interval.

   This could be things like moving a camera, label, or selection cursor that needs to exactly follow another game object that moves in Update() or via animation.

6. Then it renders the scene, producing a new image - a new rendered frame.

7. It publishes the new frame to the graphics device, to be presented to the player's screen.

8. If VSync is enabled, the game waits until the next time the screen is ready for a new image before starting over at 1.

   Otherwise, it jumps right back to 1 and does it all again - possibly going faster than the screen can display images. This means that it draws some rendered frames that the player might never see in full - they might get skipped entirely, or get seen partially because they got sent to the screen halfway through a repaint, creating an artifact called "tearing".

So, looking at all the work done during a frame interval, to produce one rendered frame, we can see that all of these statements are true:

Update() is called every frame - Unity Document says

Yes, the Update() method is called on every active script instance, for every frame interval, before drawing each rendered frame. Update() is never skipped (unlike FixedUpdate() for example).

Update() is called during a frame - Some People Says

Yes, Update() is called at step 3 of the sequence of work in each frame interval to produce a rendered frame.

Update() is called once per frame - Some People Says

Yes, each active instance's Update() is called only once in each frame interval. It's never called twice for the same rendered frame (unlike FixedUpdate() for example).

In your screenshot, we can see that Update() has been called 506 times since the last time the console was cleared. If you have just one instance of your script in your scene, then this means 506 frames have been drawn in that time. (If you had two instances of this script, then this would represent 253 frames, calling Update once on each instance every frame)