FPS how calculate this?

In my OpenGL book, it says this:

"What often happens on such a system is that the frame is too complicated to draw in 1/60 second, so each frame is displayed more than once.开发者_如何学运维 If, for example, it takes 1/45 second to draw a frame, you get 30 fps, and the graphics are idle for 1/30 1/45 = 1/90 second per frame, or one-third of the time."

In the sentence that say "it takes 1/45 second to draw a frame, you get 30 fps", why do I get only 30 fps? Woudln't 45 fps be more correct?

---

The graphics card will normally only buffer one frame ahead.

If it takes 1/45 of a second to draw a frame, then at the 1/60 of a second mark, the previous frame will be redisplayed. At the 1/45 mark, the next frame is done - but the card doesn't have a free buffer to start rendering the next one, so has to sit idle until 1/30, where it can send out that frame and start working on the next one.

This is with VSync enabled - if you disable it, instead of getting the 30FPS framerate and an idle card 1/3rd of the time, the card will start redrawing immediately, and you'll get screen tearing instead.

---

It's correct. You'd get 45 fps, but the system is slowing it down to 30 fps, to achieve a smooth framerate on 60Hz (60 redraws per second) monitors.

Because you need to draw something every 1/60 seconds on a 60Hz monitor, and can't draw a "half-frame", you must draw the previous frame. So if you 60 time per second you once draw the real frame, and every 2 frames you draw the former, then you get 30fps despite the fact that you could manage 45fps.

---

So yes, as others have said, this is due to your graphics waiting for v-sync prior to starting to generate the next frame.

That said...

Beware, not all monitors refresh at 60Hz. 60fps vs 30fps becomes 70fps vs 35fps on a 70Hz display.

If you don't want to get your card to wait for the v-sync before starting next frame, but still avoid the tearing, use triple buffering. The GPU then ping-pongs rendering to 2 buffers while the 3rd is displayed. The v-sync event is what triggers the swap to the "currently finished" back buffer. This is still not really great, because you end up with some frames that stay on the screen more often than others: with your 1/45 rendering, a frame will stay for 1/30s and the next for 1/60, giving some jerkiness.

Last, with the advent of offscreen rendering (rendering to non-displayed buffers), it's in theory possible for a driver to not wait for the v-sync before starting on the next frame, if the early work of that next frame happens to not touch the display surface. I don't think I've ever seen a driver be that smart though.