Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???
From: dan on 10 Mar 2010 11:47
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


From: Tom Serface on 10 Mar 2010 12:32
I would be really surprised if this were MFC's fault. Have you tried
throttling the messages, like only sending on every 5 or something like
that?

Tom

"dan" <dan(a)nospam.com> wrote in message
news:OQxdxFHwKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> 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
>
>
From: Giovanni Dicanio on 10 Mar 2010 12:53
"dan" <dan(a)nospam.com> ha scritto nel messaggio
news:OQxdxFHwKHA.5940(a)TK2MSFTNGP02.phx.gbl...

> 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?

I believe you can get smooth D3D animation in an MFC app as well.

IIRC, the DX SDK has a sample MFC application doing some realtime 3D
rendering with D3D.

Moreover, you may find this article on CodeProject helpful:

http://www.codeproject.com/KB/directx/Direct3DSDI.aspx

Giovanni




From: Tom Serface on 10 Mar 2010 13:27
I would think this would be more dependent on the graphics processor than
the coding language. It might work on one computer really well, but on
another not so well with the same executable.

Tom

"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
news:uj8rkqHwKHA.5812(a)TK2MSFTNGP02.phx.gbl...
> "dan" <dan(a)nospam.com> ha scritto nel messaggio
> news:OQxdxFHwKHA.5940(a)TK2MSFTNGP02.phx.gbl...
>
>> 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?
>
> I believe you can get smooth D3D animation in an MFC app as well.
>
> IIRC, the DX SDK has a sample MFC application doing some realtime 3D
> rendering with D3D.
>
> Moreover, you may find this article on CodeProject helpful:
>
> http://www.codeproject.com/KB/directx/Direct3DSDI.aspx
>
> Giovanni
>
>
>
>
From: dan on 10 Mar 2010 14:28

"Tom Serface" <tom(a)camaswood.com> wrote in message
news:%23CPj0eHwKHA.5812(a)TK2MSFTNGP02.phx.gbl...
>I would be really surprised if this were MFC's fault. Have you tried
>throttling the messages, like only sending on every 5 or something like
>that?
>
> Tom
>
[...]

Tom,

I'm not sure if I got your question right but ...

I did try different timer intervals. I started with 33ms and then went down
to 16ms. Even at 17ms the application behaved normally. The UI locks up
only if I set the timer to an interval 16ms or less (i.e. closest to screen
refresh rate).

There is definitely a link between screen refresh rate and the animation
rate. My monitor also supports 75hz refresh rate for the same screen
resolution. When set for 75hz the 16, 15, and 14 ms timer intervals no
longer lock up UI. But 13ms interval does.

I tested the app on 32-bit XP Pro and 64-bit Win7 Home Premium and got
identical results.

I also determined that PostMessage() on its own is not a problem. The UI
functions properly if I remove 3D rendering from the message handler.

So, the CPU utilization is very low in all cases, the rendering code
performs well with 17+ms timer interval @60hz and 14+ms timer interval
@75hz.

I must be missing something really obvious here. Any more suggestions?

Thanks again,
Dan


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