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

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:knjgp5lk78pcmtk9lmprrceckg263dc180(a)4ax.com...
>
> 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:
>
[...]

I do get intervals < 15ms on Windows 7 with monitor resolution set to 75hz.
When I set timer interval to 13ms I get effective intervals from 13.5 to
13.9. It gives me 72 to 74 frames per second. The 3D animations are very
smooth at this rate. The problem is that UI does not respond while the
animations are running.

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.

On my XP system I could only test the app at 60hz. With timer interval set
to 17ms I could get effective intervals from 17.5 - 17.9. With timer
interval set to 16ms I got effective interval of ~17.2 (and of course locked
up UI).

So, for whatever reason, the monitor frequency does make a difference in UI
responsiveness of my MFC app. For example, at 60hz monitor frequency any
timer interval <= 16ms locks up the app's UI. At 75hz only timer intervals
<= 13ms do the same.

There has to be something somewhere in either MFC or Windows that relies on
vertical refresh for timing. As I mentioned in my other posts, the CPU
utilization is very low when animations are running. Is it possible that a
resource or a queue is being looked at by some code at a predefined
frequency (locked to vsync)?

I used queue timers instead of timeSetEvent() since MS states that
timeSetEvent() is obsolete. I'm still struggling with making queue timers
to give me a precise beat.

Thanks.


From: Scott McPhillips [MVP] on 11 Mar 2010 11:19
"dan" <dan(a)nospam.com> wrote in message
news:OAJB6KTwKHA.5940(a)TK2MSFTNGP02.phx.gbl...
> I do get intervals < 15ms on Windows 7 with monitor resolution set to
> 75hz. When I set timer interval to 13ms I get effective intervals from
> 13.5 to 13.9. It gives me 72 to 74 frames per second. The 3D animations
> are very smooth at this rate. The problem is that UI does not respond
> while the animations are running.


Are you painting in the timer message handler? If so I suggest you do only
Invalidate() in the timer message handler and do all painting in
OnDraw/OnPaint. That should keep the message queue flowing much better.

--
Scott McPhillips [VC++ MVP]

From: dan on 11 Mar 2010 11:57

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:OOGYnaTwKHA.1692(a)TK2MSFTNGP04.phx.gbl...
> "dan" <dan(a)nospam.com> wrote in message
> news:OAJB6KTwKHA.5940(a)TK2MSFTNGP02.phx.gbl...
>> I do get intervals < 15ms on Windows 7 with monitor resolution set to
>> 75hz. When I set timer interval to 13ms I get effective intervals from
>> 13.5 to 13.9. It gives me 72 to 74 frames per second. The 3D animations
>> are very smooth at this rate. The problem is that UI does not respond
>> while the animations are running.
>
>
> Are you painting in the timer message handler? If so I suggest you do
> only Invalidate() in the timer message handler and do all painting in
> OnDraw/OnPaint. That should keep the message queue flowing much better.
>
> --
> Scott McPhillips [VC++ MVP]

I do not use WM_TIMER messages and do not paint in OnDraw/OnPaint. Instead,
I use a queue timer (created by CreateTimerQueueTimer()) and then do
rendering using Direct3D APIs.
The queue timer calls a callback function at a specified interval (or rather
close to the specified interval). The callback function simply posts a
WM_APP_n message to CView derived window. The WM_APP_n handler then renders
animations by calling appropriate methods on a Direct3D device (e.g.
BeginScene(), ..., EndScene(), Present(), etc.).



From: Giovanni Dicanio on 11 Mar 2010 12:51
"dan" <dan(a)nospam.com> ha scritto nel messaggio
news:O6j$FwTwKHA.5956(a)TK2MSFTNGP05.phx.gbl...

> I do not use WM_TIMER messages and do not paint in OnDraw/OnPaint.

I believe the best approach is doing the D3D rendering in OnDraw, as Scott
explained.

Did you read the article I posted above? I think that the D3D rendering
methods are called from OnDraw method of the view class.

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

Giovanni





From: dan on 11 Mar 2010 13:47

"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
news:eR063NUwKHA.4636(a)TK2MSFTNGP06.phx.gbl...
> "dan" <dan(a)nospam.com> ha scritto nel messaggio
> news:O6j$FwTwKHA.5956(a)TK2MSFTNGP05.phx.gbl...
>
>> I do not use WM_TIMER messages and do not paint in OnDraw/OnPaint.
>
> I believe the best approach is doing the D3D rendering in OnDraw, as Scott
> explained.
>
> Did you read the article I posted above? I think that the D3D rendering
> methods are called from OnDraw method of the view class.
>
> http://www.codeproject.com/KB/directx/Direct3DSDI.aspx
>
> Giovanni
>

I did read the article (and replied below :)).

Anyway, WM_TIMER (used in the sample referenced above) does not give me the
smoothness of 3D animations that a timer-queue timer does when its interval
is set close to the screen refresh rate (e.g. 16ms @60hz or 13ms @75hz).

I have a test app where I can switch between 3 different timing techniques:
1) WM_TIMER with USER_TIMER_MINIMUM
2) timer-queue timer with 16ms interval (screen @60hz) and a callback that
posts WM_APP_n messages whose handler does 3d rendering
3) timer-queue timer 16ms interval (screen @60hz) and a callback that does
3d rendering

When the app does nothing else except for rendering a single animation then
all techniques are comparable. The WM_TIMER seems to be preferred one
because app's UI responds to keyboard/mouse while animation is running.

When the app starts another animation (GDI or Direct3D based) or starts
playing a media file then the WM_TIMER technique becomes unreliable - a lot
of hesitations, etc. As others pointed out this behaviour is expected.

As it stands now, I have two separate issues: a) finding a right timing
technique for Direct3D animations and b) finding out why certain timer-queue
timer intervals lock up my app's UI. If I could solve the latter issue then
I would definitely go with technique 2) or 3).

Thanks.






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