Re: What is the best way to drive (time) animations?
"dan" <dan@nospam.com> wrote in message
news:OiClr2svKHA.5340@TK2MSFTNGP04.phx.gbl...
"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.25fdd9bf63bf9afd989845@news.sunsite.dk...
In article <uOCpDuhvKHA.5940@TK2MSFTNGP02.phx.gbl>, dan@nospam.com
says...
Hi,
I've been using WM_TIMER for 2d animations. That is, I'd set a timer to
a
certain frequency and then move animation frames on timer messages.
This
approach was simple and sufficient for me in the past.
I now need to animate 3D objects using Direct3D. I need more
consistency
and probably a bit higher frame-per-second than the one provided by
WM_TIMER.
Have you looked into multimedia timers, timeSetEvent in particular?
--
Later,
Jerry.
Jerry,
Thanks for the reply.
I did have a look at timeSetEvent (and the newer QueueTimerEvent) but at
the time I thought that it would not work for me. The primary reason
being that the timer callbacks would take place on a different thread than
the thread that created the target window. Although I have seen msdn
article(s) on gdi and mult-threads I have also seen many articles
discouraging doing anything to a window from another thread. One specific
comment on msdn site (I think I read it in DirectShow's VMR7 or VMR9
section some time ago) that explained why windowless mode for video
renderers had been introduced. They basically said that it was done
because drawing from another thread could lockup the UI thread, or
something like that.
Although I have no problem coding multi-threaded apps, I'm not that strong
in windowing APIs on Windows. I'd rather stay away from doing anything to
a window from another thread if possible. My app needs to runs 24x7.
But again, I suspect that your recommendation of timeSetEvent() was based
on your past experience. If my assumption is correct, could you please
let me know how you dealt with it?
Thanks again,
Dan
There are a couple of possible ways to use timeSetEvent (which comes in on a
system thread) and still do your painting in your main thread. The first is
to call Invalidate on your window's HWND from the timer thread. That will
cause a WM_PAINT. It's debateable whether Invalidate accesses the window
from the thread, but in my experience this is thread safe.
Another possibility is to simply PostMessage or SendMessage a user-defined
message (WM_APP + n) to the HWND. The message handler in the main thread
(use ON_MESSAGE in the message map) can then do Invalidate or even paint
directly. The advantage here is that the WM_APP+n message is not low
priority like WM_TIMER, so you will get a more consistent frame rate than
WM_TIMER can give you.
--
Scott McPhillips [VC++ MVP]