[Qt-interest] artifacts in animation - was is it the right way to calculate fps?

Mon Jun 28 11:00:35 CEST 2010

Parta wrote:
>> On Sat, 2010-06-26 at 23:23 +0530, lists4pghanghas wrote:
>>     
> @Jason,
>   
>> its not locked to 30, I dint write any code to do that. I guess you are
>> referring to calling update/paint manually on some timer event and
>> disabling updates in b/w. Thats the only way i can think for locking the
>> fps to some value. As for now I only wanted to know whether I was using
>> the right method to calculate fps because the UI doesn't look that smooth.
>>
>> @Noam, Thanks for another method. I will try that that on Monday if it
>> gives me different results.
>> But I am getting confident that my method is also ok - one in which I
>> increment the counter in paint because its a QWidget and whole of the
>> widget is painted. This was a simple test with simple paintings.
>> My previous experience of bad fps (with which I was comparing) was with
>> QGV but that was significantly bigger app and larger drawings. And
>> probably I wrote some inefficient code also (was fresh on the Qt boat).
>>
>> But despite higher fps, my animations is not smooth. I tried the same
>> kind of painting both in QGV and QWidget and there were artifacts when
>> the frames moved. The artifact was "like an old TV having a line
>> traveling up and down". I will post the test code on Monday if somebody
>> wants to have a look.
>>
>> My use case is that I draw some images (about 45 (240x180)) in a widget
>> or Scene and than use horizontal scrollbar value for animation using
>> Qproperty animation.
>>
>> Other observations that I made on my desktop (with Nvidia graphics).
>>
>> QWidget/QGV with X11 paintengine - 46fps
>> QWidget/QGV with raster                 - 38fps
>> QWidget/QGV with opengl engine     - 5fps
>> opengl performance was surprising despite the use case seems very
>> favourable to OGL
>>
>> On my embedded target hardware I have only raster and it gave around
>> 36fps for QWidget and 32 for QGV.
>>
>> But the artifacts were visible on both the machines.
>>
>> On Saturday 26 June 2010 12:59 AM, noam.rosenthal at nokia.com wrote:
>>     
>>> The way I prefer to measure FPS is to create an arbitrary 10ms timer in the UI thread (using the lower level QObject::startTimer and timerEvent), and add to the frame count every time it pops. Because the timer is in the UI thread, it would be affected by all the delays in the paint event, animation framework or other events. Every few seconds I'd calculate average (and optionally the standard deviation).
>>> The nice thing about this is that (1) it measures ALL delays and not just paint time (2) it can be side-loaded to any existing application.
>>>
>>> @Pritam: the reason you're seeing high FPS is because paint events might be called more than once per frame, if your QGraphicsView has an update mode that's not FullViewportUpdate, for example. Paint events are not equivalent to frames that the user sees, and the same goes to the QAnimation stuff, for example when you have two animations running concurrently.
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: qt-interest-bounces at trolltech.com
>>>> [mailto:qt-interest-bounces at trolltech.com] On Behalf Of ext Jason H
>>>> Sent: Friday, June 25, 2010 11:01 AM
>>>> To: Constantin Makshin; Qt Interest
>>>> Subject: Re: [Qt-interest] is it the right way to calculate fps?
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Qt-interest mailing list
>>>> Qt-interest at trolltech.com
>>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> Qt-interest mailing list
>>> Qt-interest at trolltech.com
>>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>>
>>>
>>>       
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>     
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100628/9b6f09b5/attachment.html