Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???
From: Ajay Kalra on 11 Mar 2010 14:32
On Mar 10, 11:47 am, "dan" <d...(a)nospam.com> wrote:
> Hi,
>
> As recommended by Jerry and Scott in this newsgroups, I experimented with
> CreateTimerQueueTimer and PostMessage(WM_APP_...) to drive animations in a
> CView derived window.  I have 2 types of animations: GDI based and Direct3D
> based.  I noticed that Direct3D based animations were really smooth when I
> ran them at a frequency which was close to the adapter's refresh rate: 60hz.
> I was quite pleased to see the smoothness of the animations and a very low
> CPU usage (alternating between 3-4%).
>
> Unfortunately the app's UI (e.g. closing/sizing/moving the frame, menus,
> etc.) became non-responsive.  Other applications behaved normally so it
> wasn't a system wide UI lockup.
>
> It is a bit puzzling to me that at such a low CPU usage the UI becomes
> unresponsive.  Also, I can run animations at ~57 frames per second (which I
> get when the timer delay is set to 17ms) and lower with no problem - the UI
> responds as expected.  Unfortunately animations are not that smooth as at 60
> frames per second (timer delay 16ms).
>
> Does this sound like an MFC issue?  Is this because the idle processing is
> not taking place?  Any workarounds?  Would a non-mfc app behave better?
>
> Thanks,
> Dan


I wouldnt do what you are trying to do. You *have* to throttle
messages if the rate is faster than 200ms. I develop Trading
applications where Refresh rate is important. We udpate screen ever
250ms or so. Thats the best human eye can discern. Painting more often
than 4-5 times/sec is wasted. Traditional model is to have a queue
which updates at the rate the data is coming in and then a timer 4/sec
refreshes the window with then latest data.

--
Ajay

From: dan on 11 Mar 2010 19:03
[...]
> I wouldnt do what you are trying to do. You *have* to throttle
> messages if the rate is faster than 200ms. I develop Trading
> applications where Refresh rate is important. We udpate screen ever
> 250ms or so. Thats the best human eye can discern. Painting more often
> than 4-5 times/sec is wasted. Traditional model is to have a queue
> which updates at the rate the data is coming in and then a timer 4/sec
> refreshes the window with then latest data.
>
> --
> Ajay

Ajay,

Thanks for the response. I think that you misunderstood my original post
when it comes to 3D animations. When I run the animation at a given rate
I'm not trying to present a different info on each frame so people can
visually grab it. I'm trying to move objects across the screen, for
example, and possibly rotate them while moving them. This has to be very
smooth and the frame rate has to be > 25.

Thanks.


From: Jerry Coffin on 12 Mar 2010 11:01
In article <OAJB6KTwKHA.5940(a)TK2MSFTNGP02.phx.gbl>, dan(a)nospam.com
says...

[ ... ]

> If I increase the timer interval to 14ms (getting effective average
> interval of ~14.5ms) I do not have any problems with UI.
> Unfortunately animations are no longer as smooth as with 13ms timer
> interval.

Something about that sounds...suspect. Just for reference, when you
go to a movie theater, the "animations" you watch are playing at only
32 frames per second.

--
Later,
Jerry.
From: Tom Serface on 12 Mar 2010 15:19
Just curious. When you ran your tests were they always on the same machine?
Could the speed of the graphics processor be important?

Tom

"dan" <dan(a)nospam.com> wrote in message
news:O#AN4dXwKHA.1796(a)TK2MSFTNGP02.phx.gbl...
>
> Thanks for the response. I think that you misunderstood my original post
> when it comes to 3D animations. When I run the animation at a given rate
> I'm not trying to present a different info on each frame so people can
> visually grab it. I'm trying to move objects across the screen, for
> example, and possibly rotate them while moving them. This has to be very
> smooth and the frame rate has to be > 25.
>
> Thanks.
>
From: dan on 12 Mar 2010 17:03

"Jerry Coffin" <jerryvcoffin(a)yahoo.com> wrote in message
news:MPG.2604123da6005c0c98984e(a)news.sunsite.dk...
> In article <OAJB6KTwKHA.5940(a)TK2MSFTNGP02.phx.gbl>, dan(a)nospam.com
> says...
>
> [ ... ]
>
>> If I increase the timer interval to 14ms (getting effective average
>> interval of ~14.5ms) I do not have any problems with UI.
>> Unfortunately animations are no longer as smooth as with 13ms timer
>> interval.
>
> Something about that sounds...suspect. Just for reference, when you
> go to a movie theater, the "animations" you watch are playing at only
> 32 frames per second.
>
> --
> Later,
> Jerry.

MPAA, PAL, NTSC display frames at 24-30 hz (i.e. not taking into account
interlaced fields) and we as humans do not have a problem with it.
Unfortunately for my 3D animations I need to move objects across the screen
relatively fast and smooth.

A very simple test case would be to scroll a line of text 1280 pixels wide
and 40 pixels high across a window which is at least 1280 wide. Even with a
simple and low priority WM_TIMER the difference is tremendous when you set
the interval to 33ms and 16ms (assuming @60hz monitor frequency and no other
screen activity). At 33ms interval (which gives me ~30 fps) the scroll is
quite jerky - not much different than a marquee in Web browsers. If I have
the interval set to 16ms I get a very smooth and steady scroll comparable in
quality to stock tickers that you can see on TV.

In the past I worked with professional video cards (mainly from Matrox) but
it was not on Windows platform. I had a ability to hook up my timing and
drawing to a vertical blanking interrupt. It was so simple and reliable. I
realize that vsync is not available on Windows (although I can configure
Direct3D to present at vsync) but I need a reliable way to present buffers
to the Direct3D device at a vsync rate as close as possible.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???