What is the best way to drive (time) animations?
in [MFC]
|
From: dan on 7 Mar 2010 12:27 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. Most of the non-mfc examples that I have seen use a combination of performance counter and main message loop. Example: for (;;) { while (::PeekMessage(&(pState->m_msgCur), NULL, 0, 0, PM_REMOVE)){ ::TranslateMessage(&(pState->m_msgCur)); ::DispatchMessage(&(pState->m_msgCur)); } ProcessAnimations(); // use performance counter to check if the next frame should be moved } I'm not quite sure how to implement this in an mfc app. I've seen some suggestions that OnIdle() might be a good place. I tried it but it did not work well - timing was not better than WM_TIMER's or much worse if there was no activity on the screen (e.g. re-drawing window's regions). I had a look at Run() method of the main app. It seems like a good place but it is a bit complex. I do not quite get the idle processing. The Run() method has one main loop and two inner-loops (phase1 and phase2). I tried to put my ProcessAnimiations() in each inner-loop but did not get the expected results. Could someone please give me some idea how to deal with the above? Thanks, Dan
From: Jerry Coffin on 7 Mar 2010 23:26 In article <uOCpDuhvKHA.5940(a)TK2MSFTNGP02.phx.gbl>, dan(a)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.
From: dan on 8 Mar 2010 09:42 "Jerry Coffin" <jerryvcoffin(a)yahoo.com> wrote in message news:MPG.25fdd9bf63bf9afd989845(a)news.sunsite.dk... > In article <uOCpDuhvKHA.5940(a)TK2MSFTNGP02.phx.gbl>, dan(a)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
From: Scott McPhillips [MVP] on 8 Mar 2010 11:15 "dan" <dan(a)nospam.com> wrote in message news:OiClr2svKHA.5340(a)TK2MSFTNGP04.phx.gbl... > > "Jerry Coffin" <jerryvcoffin(a)yahoo.com> wrote in message > news:MPG.25fdd9bf63bf9afd989845(a)news.sunsite.dk... >> In article <uOCpDuhvKHA.5940(a)TK2MSFTNGP02.phx.gbl>, dan(a)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]
From: dan on 8 Mar 2010 13:09 "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:OuDOSqtvKHA.4908(a)TK2MSFTNGP06.phx.gbl... [...] > > > 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] Scott, Thanks for the reply. I think that calling Invalidate() would be ideal but since I cannot be absolutely sure that it is thread safe then I need to stay away from it. If, for example, I get a report about the app locking up once a week (or even month) I will always tend to think that Invalidate() is the cause. I was also considering PostMessage() in the past but was afraid that this would flood the message queue. Do you see any problems with posting ~30 WM_APPn messages a second? As per my original post, is there a way that I could override CWinApp's Run() method and use QueryPerformanceCounter() to drive animations? Or, is this approach not recommended for mfc apps? Thanks, Dan
|
Next
|
Last
Pages: 1 2 3 Prev: proper way to close a socket? Next: DrawText and measuring offset strings |