[Qt-interest] is it the right way to calculate fps?

[Jason H]

He's probably looking at it from the perpective of "I'm redrawing too much, so my other parts of my system are suffering"
The question is, are all other processes yielding CPU, causing high FPS, or is it drawing too much, stealing CPU? And also what is generating so many paint events if the FPS is locked at 30?

See enum QGraphicsItem::CacheMode, but do not use NoCache  (default)



----- Original Message ----
From: Constantin Makshin <cmakshin at gmail.com>
To: Qt Interest <qt-interest at trolltech.com>
Sent: Thu, June 24, 2010 3:46:52 PM
Subject: Re: [Qt-interest] is it the right way to calculate fps?

(1) should be more correct, IMHO, because it counts actual redraws instead of some updates that may be ignored for some reason (vsync, etc.).

And why don't you like high FPS values? :)
Or your FPS counter seems to show wrong values (i.e. the animation is significantly less smooth than you expected from shown FPS value)?

On Thursday 24 June 2010 21:18:51 lists4pghanghas wrote:
> Hi
> 
> Over time I have used two methods for calculating FPS during animations 
> in my qt progs.
> and always had doubts whether I am getting the right nos or not
> 
> 1) increment a counter in paint event of widget whose fps I want to know 
> and then use that to calcualte fps at the end of animation
> 2) increment counter everytime animation api emits signal 
> valuechanged/framechanged.
> 
> Are these methods guaranteed correct in every usecase. And are there any 
> better methods ways to do this.
> 
> I am asking this question becaues I got a very hight number with these 
> methods recently when using scrollArea. That no seems unlikely on my 
> embedded hardware.
> 
> Thanks
> Pritam
_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest