How to Address Resource Use of PeekMessage Calls in Mobilized Applications

Submit New Article

June 23, 2008 2:40 PM PDT


Challenge
Determine and minimize the battery-life impact of PeekMessage calls in Windows*-based mobilized applications. When discussing optimization techniques for applications running on battery-powered devices, some application developers doubt or do not understand the need to be concerned with this issue.

With PeekMessage being heavily used for years by many legacy applications as the key component of a message loop, it becomes important to account for power issues in the applications. Basically, the PeekMessage call ties up the system by keeping it busy checking for a message.

Solution
Be aware of the power implications and enable a proper idle state when the program is idle. An application can be written to be power-friendly, allow windows to go idle, and also monitor roughly how long the application has been idling without processing a message. Given the difficulties of using PeekMessage properly, alternative methods of dealing with a potential PeekMessage situation have been devised.

One way to directly control how PeekMessage is used in your application is to build your own message loop. By ensuring you cover the essential elements as found in the Microsoft Foundations Classes* (MFC*) main message loop, your application can directly control the message pump. Following is a short pseudocode sample that is compatible with MFC:

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++ ) )
        ;  
    // Perform some background processing here 
    // using another call to OnIdle
}

In this code, as long as there is idle processing going on, PeekMessage will be called. The PumpMessage is used to perform normal message translation and dispatching. The problem in using this code is with the PumpMessage call. While the source can be found in ThrdCore.cpp, it is officially undocumented and thus could be subject to change in future releases.

The problem with using PeekMessage in a loop is that Windows cannot go idle. A power-friendly application will process all the messages and background processing and then call WaitMessage to go to sleep until new messages arrive. Using WaitMessage frees the system to focus on other tasks:

if (PeekMessage(...) != NULL)
   // IF there is a message, translate &
 dispatch it
else if (there is background processing to do)
   // do your background processing
else 
   // No background processing, no messages waiting - go to sleep
   WaitMessage();

Writing your application to manage itself, as shown in the above pseudocode, will help improve the power usage on battery-powered systems.

Source
PeekMessage: Optimizing Applications for Extended Battery Life