Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???
From: dan on 10 Mar 2010 14:52

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

Most of the samples that I have seen do not use MFC. The ones that do use
MFC use WM_TIMER to drive 3D animations. This is unfortunately not
acceptable in my case.

Ideally I'd like to do in my MFC app what non-MFC apps do. I think I'll give
overriding CWinApp's Run() method another try. I just need to figure out
what is going on there with idle processing.

Thanks,
Dan


From: Tom Serface on 10 Mar 2010 18:39
Doesn't hurt to try if you have a small enough test case so it doesn't waste
too much of your time. MFC is such a thin layer on Win32 SDK that I can't
imagine it causing much of the problem, but I'd be curious to hear about
your experience if you do try it without MFC.

I think some of the new capabilities for parallel processing in VC++ 2010
may be interesting if you could take advantage of multiple cores and
hyperthreading to do some of the processing work. But, that doesn't have
anything to do with MFC.

Tom

"dan" <dan(a)nospam.com> wrote in message
news:uucwBtIwKHA.5244(a)TK2MSFTNGP05.phx.gbl...

> Most of the samples that I have seen do not use MFC. The ones that do use
> MFC use WM_TIMER to drive 3D animations. This is unfortunately not
> acceptable in my case.
>
> Ideally I'd like to do in my MFC app what non-MFC apps do. I think I'll
> give overriding CWinApp's Run() method another try. I just need to figure
> out what is going on there with idle processing.
>
> Thanks,
> Dan
>
From: Joseph M. Newcomer on 10 Mar 2010 21:00
Time messages are only dispatched if the message queue is empty. If you PostMessage fast
enough, you will always have a nonempty queue. The whole point of Direct3D is that it
addresses these serious issues by providing a timer than is not sensitive to the message
queue saturation. Note that timer resolution is at best 15ms, which is close to your
refresh time, so you will have anomalies caused by what is called "gating error" which is
what happens when you samping interfval is close to your timer quantum. Also, note that
"timer" notifications means that *approximately* evey n milliseconds the thread is marked
as "runnable". There is NO guarantee if actually runs. This is up to the scheduler,
which has its own agenda. In general timer messages at fine intervals are pretty useless
in Windows.

It has nothing to do with MFC or idle processing; you are seeing an intrinsic artifact of
WIndows behavior here.

joe


On Wed, 10 Mar 2010 11:47:51 -0500, "dan" <dan(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
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 10 Mar 2010 21:02

Screen refresh rare is irrelevant. Motherboard clock tick rate (15ms) is the limiting
factor. You cannot have intervals < 15ms effectively. It just won't work. timeSetEvent
will work better, but that is really part of how Direct3D handles timing. Note the
callback of timeSetEvent is executed in a separate thread.
joe

On Wed, 10 Mar 2010 14:28:52 -0500, "dan" <dan(a)nospam.com> wrote:

>
>"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
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 10 Mar 2010 21:03
WM_TIMER is not acceptable for small intervals.
joe
N
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???