Prev: Socket connection error - 10061
Next: Preventing memory and resource leaks with GDI Objects ???
From: dan on 12 Mar 2010 18:29
I ran the test on two quite different machines - different hardware and OS.
One was on a 4 year old laptop running 32-bit XP Pro and the other one was
a new 64-bit Windows 7 desktop. As far as I could tell, the app behaved
identically on both systems when their screen refresh rates were set to
60hz. On Windows 7 machine I could change the refresh rate to 75hz and get
down to 14ms timer interval without locking up UI. I did not have 75hz
refresh rate available on the laptop.

Although there could've been some differences in speed - I'm not sure about
it. For example, I did not time how long it took for a given object to move
from one side of a window to another. I was more concerned with smoothness.
But it looked like the timing was either identical or very close.

I found a workaround for not locking up UI at 16ms @60hz and 13ms @75. I
put some logic in the timer callback function (this is a case where I used a
queue timer and PostMessage()) so it did not post WM_APP_n messages if the
previously posted message had not been processed yet.

I'm still quite puzzled by the fact that I have to do it at 16ms @60hz and
at 13ms @75hz. There has to be a wait/block somewhere in a message
processing loop that depends on the current refresh rate because, as I
stated before, CPU utilization is close to nothing. Again, not sure if this
is MFC or Windows. To me, MFC's idle processing would be a primary suspect,
but maybe only because I haven't had a serious look at it yet.


"Tom Serface" <tom(a)camaswood.com> wrote in message
news:%232YigFiwKHA.5340(a)TK2MSFTNGP04.phx.gbl...
> 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: Joseph M. Newcomer on 16 Mar 2010 21:36
You can get finer resolution if you are not using timer messages, but, for example, just
going for raw graphics. The formal specs for WM_TIMER do not guarantee resolution better
than the motherboard timer tick. but if you are invalidating often, you will probably get
drawing synced to the vertical retrace interval (the frame time) simply because of how the
double-buffering in Win7 works.

How do you know your events are happening 13.5 to 13.9ms apart? (There are several ways,
I'm curious which one you are using). But the UI does not respond because it is spending
all of its time drawing.

For this reason, some people choose to do their drawing in a separate thread, so it does
not impact the UI performance. One way to handle this is to have the OnPaint handler just
singnal the secondary thread to do the drawing, and all the computation happens in the
secondary thread, leaving the main UI thread responsive. Note also that an Invalidate()
followed by an immediate UpdateWindow() defeats the normal algorithm that WM_PAINT is
dispatched only when the UI thread is idle, thus essentially saturating the UI thread with
drawing code. And if you are not drawing in the OnPaint handler, but in the OnTimer
handler (a Really Bad Idea) then you guarantee that your UI will be non-responsive because
you are spending all of your time in the drawing routine. Gating error (a phenomenon of
discrete event-driven systems) pretty much ensures that while a time message is
dispatched, nothing else will be.
joe

On Thu, 11 Mar 2010 10:51:22 -0500, "dan" <dan(a)nospam.com> wrote:

>
>"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.
>
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 16 Mar 2010 21:41
Video plays at 29.997 frames/second (close enough to 30) but films animation plays at 24
frames/second (standard film projection rate for 35mm and 16mm film; the reason old silent
films seem so jerky and disconnected in modern theaters is that they were shot at, and
should be shown at, 18 frames/second, but no modern projectors allow that, so they show at
24 frames/second [yes, that history-of-films class I took as a undergraduate was good for
something after all! A friend had to play the musical score for a silent film, and the
score was written for 18fps projection; he had one rehearsal and had to cut random pieces
out so he could keep the music more or less in sync with the action]
joe

On Fri, 12 Mar 2010 09:01:30 -0700, Jerry Coffin <jerryvcoffin(a)yahoo.com> wrote:

>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.
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 16 Mar 2010 21:44
See below...
On Fri, 12 Mar 2010 18:29:36 -0500, "dan" <dan(a)nospam.com> wrote:

>I ran the test on two quite different machines - different hardware and OS.
>One was on a 4 year old laptop running 32-bit XP Pro and the other one was
>a new 64-bit Windows 7 desktop. As far as I could tell, the app behaved
>identically on both systems when their screen refresh rates were set to
>60hz. On Windows 7 machine I could change the refresh rate to 75hz and get
>down to 14ms timer interval without locking up UI. I did not have 75hz
>refresh rate available on the laptop.
>
>Although there could've been some differences in speed - I'm not sure about
>it. For example, I did not time how long it took for a given object to move
>from one side of a window to another. I was more concerned with smoothness.
>But it looked like the timing was either identical or very close.
>
>I found a workaround for not locking up UI at 16ms @60hz and 13ms @75. I
>put some logic in the timer callback function (this is a case where I used a
>queue timer and PostMessage()) so it did not post WM_APP_n messages if the
>previously posted message had not been processed yet.
>
>I'm still quite puzzled by the fact that I have to do it at 16ms @60hz and
>at 13ms @75hz. There has to be a wait/block somewhere in a message
>processing loop that depends on the current refresh rate because, as I
>stated before, CPU utilization is close to nothing. Again, not sure if this
>is MFC or Windows. To me, MFC's idle processing would be a primary suspect,
>but maybe only because I haven't had a serious look at it yet.
****
OnIdle is called only when PeekMessage returns FALSE meaning the queue is empty. go read
the code to understand how this works!
joe
****
>
>
>"Tom Serface" <tom(a)camaswood.com> wrote in message
>news:%232YigFiwKHA.5340(a)TK2MSFTNGP04.phx.gbl...
>> 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.
>>>
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Jerry Coffin on 17 Mar 2010 17:00
In article <emXyX$iwKHA.1796(a)TK2MSFTNGP02.phx.gbl>, dan(a)nospam.com
says...

[ ... ]

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

I think trying to get GDI drawing fast and smooth if you're at all
willing to consider Direct3D is mostly a waste of time -- GDI really
isn't built for the job, so getting it to work well at all is going
to be difficult at best. D3D is built for the job, and getting it to
do this well is fairly trivial.

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