THE STRANGEST WM_TIMER ISSUE (only for gurus)
-
Somewhere: "SetTimer(1,10,0);" 10 means the function below is called in every "10 miliseconds" void CDDDView::OnTimer(UINT nIDEvent) { if (nIDEvent==1) { //draw a bitmap in different points to simulate an animation } } 10 miliseconds is too less for a Pentium II ,so the bitmap cant redraw at every 10 miliseconds. NOW, THE EXCITING PART: I have a CTreeCtrl in my view. When i move the mouse over the tree the bitmap redraw 3 times faster!!!!!!!!! Is there a guru on Earth to explain this??? :confused: PS: if somebody wants to see the application i'll send by e-mail. It is my graduated project. Sorry for not a good English.
-
Somewhere: "SetTimer(1,10,0);" 10 means the function below is called in every "10 miliseconds" void CDDDView::OnTimer(UINT nIDEvent) { if (nIDEvent==1) { //draw a bitmap in different points to simulate an animation } } 10 miliseconds is too less for a Pentium II ,so the bitmap cant redraw at every 10 miliseconds. NOW, THE EXCITING PART: I have a CTreeCtrl in my view. When i move the mouse over the tree the bitmap redraw 3 times faster!!!!!!!!! Is there a guru on Earth to explain this??? :confused: PS: if somebody wants to see the application i'll send by e-mail. It is my graduated project. Sorry for not a good English.
> "SetTimer(1,10,0);" 10 means the function below is called in > every "10 miliseconds" No. Windows timers use INT 8 interrupt internally, which fires at 18.2 Hz. The minimal elapsed time is about 55 ms, even if you pass 10 to SetTimer. And, OnTimer is not guaranteed to be called when time elapses - WM_TIMER messages are posted to the message queue and have the lowest priority. Tomasz Sowinski -- http://www.shooltz.com
-
> "SetTimer(1,10,0);" 10 means the function below is called in > every "10 miliseconds" No. Windows timers use INT 8 interrupt internally, which fires at 18.2 Hz. The minimal elapsed time is about 55 ms, even if you pass 10 to SetTimer. And, OnTimer is not guaranteed to be called when time elapses - WM_TIMER messages are posted to the message queue and have the lowest priority. Tomasz Sowinski -- http://www.shooltz.com
Ok! Ok! I think i didn't make myself clear! In my view derived class i have a bitmap who redraws in VM_TIMER handle.I have a tree control, and a multiline edit control too. Normaly, the bitmap move on the screen with a speed lets say "x". WHEN I MOVE THE MOUSE OVER THE TREE CONTROL, OR WHEN I SELECT THE TEXT WITHIN A MULTIEDIT CONTROL (FROM MY CView DERIVED CLASS) THE BITMAP MOVES WITH A SPEED "3*x". I KNOW THIS SOUNDS WEIRD! Why? Why? Why?
-
Ok! Ok! I think i didn't make myself clear! In my view derived class i have a bitmap who redraws in VM_TIMER handle.I have a tree control, and a multiline edit control too. Normaly, the bitmap move on the screen with a speed lets say "x". WHEN I MOVE THE MOUSE OVER THE TREE CONTROL, OR WHEN I SELECT THE TEXT WITHIN A MULTIEDIT CONTROL (FROM MY CView DERIVED CLASS) THE BITMAP MOVES WITH A SPEED "3*x". I KNOW THIS SOUNDS WEIRD! Why? Why? Why?
The Windows scheduler boosts the priority of the thread that owns the window, when a window receives input, such as timer messages, mouse messages, or keyboard input. Priority boost gives more processor time and your bitmap is redrawn faster. BTW: Do you really think that SCREAMING makes you more readable? Tomasz Sowinski -- http://www.shooltz.com
-
The Windows scheduler boosts the priority of the thread that owns the window, when a window receives input, such as timer messages, mouse messages, or keyboard input. Priority boost gives more processor time and your bitmap is redrawn faster. BTW: Do you really think that SCREAMING makes you more readable? Tomasz Sowinski -- http://www.shooltz.com
And how comes in the following cases the bitmap doesn't move faster and implicitly Windows scheduler doesnt boost the priority of my thread? 1)Put all my fingers on the keyboard. 2)Click the mouse 5 times a second OUT OF THE TREE and OUT OF THE EDIT CONTROL. Does Windows scheduler boost the priority of my thread ONLY when my view receives messages from the child windows? How can you explain that? For you it seems all right. For me not. Sorry for screaming.:((
-
And how comes in the following cases the bitmap doesn't move faster and implicitly Windows scheduler doesnt boost the priority of my thread? 1)Put all my fingers on the keyboard. 2)Click the mouse 5 times a second OUT OF THE TREE and OUT OF THE EDIT CONTROL. Does Windows scheduler boost the priority of my thread ONLY when my view receives messages from the child windows? How can you explain that? For you it seems all right. For me not. Sorry for screaming.:((
> And how comes in the following cases the bitmap doesn't move > faster and implicitly Windows scheduler doesnt boost the > priority of my thread? I have no idea - maybe your WM_KEYDOWN handler is glacially slow. You can use Performance Monitor to check what's going on with the priority base/boost. Anyway, if you want smoothly animated bitmap in your program, you'll have to create a separate "painter" thread. Tomasz Sowinski -- http://www.shooltz.com
-
> And how comes in the following cases the bitmap doesn't move > faster and implicitly Windows scheduler doesnt boost the > priority of my thread? I have no idea - maybe your WM_KEYDOWN handler is glacially slow. You can use Performance Monitor to check what's going on with the priority base/boost. Anyway, if you want smoothly animated bitmap in your program, you'll have to create a separate "painter" thread. Tomasz Sowinski -- http://www.shooltz.com
The problem is when you move your mouse, you are probably causing a an invalidate on the tree control, which means you are forcing events to repaint you window, this will be as fast as you pc can handle. SetTimer ( ... ) & OnTimer ( ... )== 55 milli seconds is the fasters you can do. Now using an idle loop you can go as fast as you like (Idle Loop Processing in MSDN) BOOL bDoingBackgroundProcessing = TRUE; while ( bDoingBackgroundProcessing ) { MSG msg; while ( ::PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) ) { if ( !PumpMessage( ) ) { bDoingBackgroundProcessing = FALSE; ::PostQuitMessage( ); break; } } // let MFC do its idle processing LONG lIdle = 0; while ( AfxGetApp()->OnIdle(lIdle++ ) ) { // Do nothing } // Now you can check if at least 10 ms have passed if so do paint, if not loop }
-
The problem is when you move your mouse, you are probably causing a an invalidate on the tree control, which means you are forcing events to repaint you window, this will be as fast as you pc can handle. SetTimer ( ... ) & OnTimer ( ... )== 55 milli seconds is the fasters you can do. Now using an idle loop you can go as fast as you like (Idle Loop Processing in MSDN) BOOL bDoingBackgroundProcessing = TRUE; while ( bDoingBackgroundProcessing ) { MSG msg; while ( ::PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) ) { if ( !PumpMessage( ) ) { bDoingBackgroundProcessing = FALSE; ::PostQuitMessage( ); break; } } // let MFC do its idle processing LONG lIdle = 0; while ( AfxGetApp()->OnIdle(lIdle++ ) ) { // Do nothing } // Now you can check if at least 10 ms have passed if so do paint, if not loop }
> The problem is when you move your mouse, you are probably > causing a an invalidate on the tree control It's not the default Windows behavior. Tree control isn't invalidated when mouse moves over it, even with TVS_TRACKSELECT style set, unless application calls InvalidateRect 'manually' in response to WM_MOUSEMOVE. Tomasz Sowinski -- http://www.shooltz.com