Timers
in [Visual C]
|
From: bob on 7 Feb 2006 01:16 Anyone know what happens if you use SetTimer to create a timer that can't process the WM_TIMER message in time? For instance, let's say you have it called 100 times a second to redraw the screen, but you run it on a slow computer. What would happen?
From: Simon Trew on 7 Feb 2006 07:55 <bob(a)coolgroups.com> wrote in message news:1139292996.833476.208460(a)g43g2000cwa.googlegroups.com... > Anyone know what happens if you use SetTimer to create a timer that > can't process the WM_TIMER message in time? For instance, let's say > you have it called 100 times a second to redraw the screen, but you run > it on a slow computer. What would happen? > WM_TIMER messages are only injected into the message queue once it is (roughly speaking) idle. So, if you set the granularity too small, then you would just not get some of the timer messages. Your only guarantee with timer messages is that you won't get them *more* frequently than what you asked for. You should poll a reliable clock (e.g. a performance counter) in your timer message handler to determine how long has actually elapsed between timer events. I realise you were just making an example, but I'm not sure that SetTimer/WM_TIMER supports that frequency of events anyway. In ages past, they used to be run off the DOS clock and so you couldn't get a resolution better than about 18.2ms (~55 ticks/sec)-- I'm not sure if that's still true, since I don't rely on WM_TIMER being used for "real time" work, and thus don't care about it. S.
From: Dan Baker on 7 Feb 2006 11:22 <bob(a)coolgroups.com> wrote in message news:1139292996.833476.208460(a)g43g2000cwa.googlegroups.com... > Anyone know what happens if you use SetTimer to create a timer that > can't process the WM_TIMER message in time? For instance, let's say > you have it called 100 times a second to redraw the screen, but you run > it on a slow computer. What would happen? My recollection of WM_TIMER messages is that if one already exists in the queue, then any new WM_TIMER messages are simply merged with the existing timer message -- meaning, you can never have more than 1 WM_TIMER message queued. What would happen: There would almost always be a WM_TIMER message in the queue, ready to be processed when the application went idle. DanB
From: bob on 7 Feb 2006 13:13 Interesting. Thanks to both of you. By any chance, do either of you know how to read USER_TIMER_MINIMUM? I thought it was a macro somewhere, but it doesn't seem to be defined. Dan Baker wrote: > <bob(a)coolgroups.com> wrote in message > news:1139292996.833476.208460(a)g43g2000cwa.googlegroups.com... > > Anyone know what happens if you use SetTimer to create a timer that > > can't process the WM_TIMER message in time? For instance, let's say > > you have it called 100 times a second to redraw the screen, but you run > > it on a slow computer. What would happen? > > My recollection of WM_TIMER messages is that if one already exists in the > queue, then any new WM_TIMER messages are simply merged with the existing > timer message -- meaning, you can never have more than 1 WM_TIMER message > queued. > What would happen: There would almost always be a WM_TIMER message in the > queue, ready to be processed when the application went idle. > > DanB
From: bob on 7 Feb 2006 13:15
also, didn't the clock tick 18.2 times/second not 55? |