Re: animation in MFC with threading
On Oct 5, 4:35 pm, Jim <j...@trainplayer.com> wrote:
I could use some advice regarding a game-like app built on MFC. It
has objects moving around the screen all the time, and the user
interacts with them. When the user does something time-consuming, the
objects pause and the movement is jerky. I am ready to take the
plunge and split it into separate threads.
I think what I want is one thread (the "animation thread") which does
all the screen drawing. The main thread would continue to handle user
interactions and updating of the data model, but no drawing. The
animation thread would have a timer (or use OnIdle) -- on every tick,
see if there's something to be redrawn, and do it.
It seems like this would work as long as (a) the animation thread
treated the data model as read-only -- render but do not modify; and
(b) the main thread didn't attempt to do any output to the view, which
would be owned by the animation thread.
Is this a reasonable strategy? Do I need semaphores or events? Any
advice welcome.
-- Jim
This is the wrong approach. Windows are bound to the thread in which
they are created. Any attempt to paint from another thread causes
that thread to pause until the window's "native" thread is available.
So it defeats the whole purpose. (Putting the view in a sepatate
thread has similar problems, since its parent is in the main thread.)
What works well is performing all user interaction and painting in the
main thread, and putting any long-running processing in a secondary
thread.