FPS Versus Frame Time

转载 2016年08月28日 18:39:31

引用至:FPS Versus Frame Time Writen by Robert Dunlop

FPS: A common yet flawed metric of game performance

One of the most common ways to provide a simple measure of graphics performance in game titles is frame rate, expressed in frames per second. However, this measure can be quite deceiving, especially with today’s faster video hardware. While it may provide some measure of performance, when it comes to making judgments regarding optimization, FPS is a very poor means of measuring application performance.

Non-Linearity of FPS values

The problem with using FPS to measure performance, from a mathematical perspective, is that it is non-linear. But before I go there, let’s look at it another way: simply put, it’s asking the wrong side of the question. When evaluating code performance in a real-time rendering application, the concern is how long it takes to render each frame, and how much time various sections of code are contributing to this. However, FPS asks the flip side of this question: it’s like asking how long it took to get from point A to point B, and being told that the car was traveling at 60 miles per hour. OK, if we know the distance from A to B we could figure it out, but it’s not what we asked!

Now, this may seem like I’m being a bit picky on the details, and to be honest part of it comes from a pet peeve. Namely, that it seems like at least once a week I see a question to the effect of:

“My application was running at 900FPS, then I added rendering of …. and my frame rate dropped to 450FPS. Why is this feature so slow? Why is it cutting my performance in half?”

Or a common variation on this theme:

“When I render a single object, I’m getting 900FPS. Then when I render a second object in the scene, my frame rate drops to 450FPS, and 300FPS if I render 3 objects!! Why is DirectX giving me such terrible performance? It obviously can’t handle many more polygons at this rate!”

I have another issue with a statement like that, but let’s address this usage of FPS first. OK, remember I said we really want to know how long it takes the code to draw a frame, right? Well, let’s take a look at how long we are talking here. There are 1,000 milliseconds in a second, so if we divide 1000 by the specified frame rates, we find the following times:

1000ms/sec / 900FPS = 1.111.. ms per frame
1000ms/sec / 450FPS = 2.222.. ms per frame
1000ms/sec / 300FPS = 3.333.. ms per frame

Hey, notice something going on here? The time is changing linear with the number of objects rendered, but the frame rate is not! In fact, it is highly non-linear, as shown in the above graph, which plots the frame rate from execution times of 1 millisecond through 40 milliseconds. Now, to illustrate how radically this can slant one’s perception of performance, do you think the person complaining above would react the same way to a drop from 60FPS to 56.25FPS? Probably not, I think… but check this out:

1000ms/sec / 900FPS = 1.111.. ms per frame
1000ms/sec / 450FPS = 2.222.. ms per frame
Increase in execution time: 1.111.. ms

1000ms/sec / 60FPS =    16.666.. ms per frame
1000ms/sec / 56.25FPS = 17.777.. ms per frame
Increase in execution time: 1.111.. ms!

Seeing such a disparity, one can see how bad conclusions could be reached, especially when comparing methods in different contexts. For example, if one method in an app caused a 900FPS to 450FPS drop, while another method in another engine caused a drop from 60FPS to 55FPS, which might you think to be more expensive? If you’ve been paying attention, you should suspect that the 5FPS drop is a sign of a greater performance cost than the 450FPS drop seen with the first method! In fact, that 5FPS drop represents 36.4% more execution time than the 450FPS drop!

So take that as food for thought if you are currently using an FPS counter as a measure of your performance. If you want a quick indication of performance between profiling sessions, use frame time instead. In the DX9 framework, for example, you could modify the CD3DApplication::UpdateStats() function to use something like:

_sntprintf( m_strFrameStats, cchMaxFrameStats, 
    _T("%.02f ms/f %.02f fps (%dx%dx%d)"), 
    1000.0f/m_fFPS, m_fFPS, ...

Till next time….

界面卡顿Jank与FPS获取

1 VSYNC 的概念    VSYNC(Vertical Synchronization)是一个相当古老的概念,对于游戏玩家,它有一个更加大名鼎鼎的中文名字—-垂直同步。 “垂直同步(vsy...
  • zhouzhengting1
  • zhouzhengting1
  • 2015年11月24日 22:08
  • 2529

帧率(FPS)计算的六种方法总结

帧率(FPS)计算是游戏编程中常见的一个话题。大体来说,总共有如下六种方法:固定时间帧数法帧率计算的公式为:fps = frameNum / elapsedTime;如果记录固定时间内的帧数,就可以计...
  • u012494876
  • u012494876
  • 2016年11月27日 22:32
  • 3595

关于CCS软件的Graph功能使用详解

我们在学习使用TI的DSP集成开发环境CCS(Code Compose Studio)时,有时特别想在线的看一下内存中的数据到底是个什么样子,或者想看一下它的频谱是个什么样子,如果不知道CCS自带有绘...
  • HJ199404182515
  • HJ199404182515
  • 2017年03月05日 14:32
  • 3423

Unity 实时显示FPS——移动端测试神器

Unity 显示FPS——移动端测试神器
  • Aries_H
  • Aries_H
  • 2016年10月11日 13:34
  • 5702

模拟电视信号介绍

第三节 电视信号   一、 模拟电视信号 模拟电视机的显像管采用红绿蓝三支电子枪,扫描显像屏,重现电视画面。R(红)、G(绿)、B(蓝)是我们常说的三基色,但是电视信号传输的时候却并不采用三基色传...
  • kinhum
  • kinhum
  • 2013年10月19日 02:43
  • 1311

Unity5.x制作FPS游戏

FPS(第一人称设计游戏) 在本文中介绍主要技术点,可以借鉴本游戏工程源码来分析点击打开链接,谢谢支持 一.枪支的创建 在GamePlaying.cs中接收鼠标左击事件,当触发后机枪将进行开火,播放音...
  • qq_33747722
  • qq_33747722
  • 2016年11月27日 16:42
  • 1037

wireshark数据分析学习

1.wireshark数据分析--http
  • u011649536
  • u011649536
  • 2015年06月15日 15:09
  • 3165

Android性能优化第(十 一)篇---卡顿分析,正确评测流畅度

一、FPS评测应用流畅度不准确说到应用的流畅度,都会想到FPS,系统获取FPS的原理是:手机屏幕显示的内容是通过Android系统的SurfaceFLinger类,把当前系统里所有进程需要显示的信息合...
  • u013263323
  • u013263323
  • 2017年02月07日 22:12
  • 2687

Android性能指标FPS获取的JAVA实现

先贴代码,待会再编辑import java.io.BufferedReader; import java.io.InputStreamReader; import java.util.ArrayLis...
  • wpyily
  • wpyily
  • 2016年09月28日 14:46
  • 2057

Android性能测试之fps获取

Android性能测试之fps获取 http://blog.csdn.net/itfootball/article/details/43084527 http://bl...
  • u011904605
  • u011904605
  • 2016年10月25日 10:47
  • 2548
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:FPS Versus Frame Time
举报原因:
原因补充:

(最多只允许输入30个字)