Re: [Dev-C++] Using MFC Timer Framework

[Per W. <pw...@ia...>]

Updating symbols on screen every 16 ms represents 60 Hz frame rate. FPS
(Frames/Per Second) games often work in this range. They do it by using
DirectX and by hogging 100% CPU. They do not idle between updates. They
evaluate game logic, update display, evaluate game logic, update display,
... Normally no sleep waiting for any tick events, and they only work well
while having focus - Windows allows the currently focused application to
hog the CPU a lot harder than other programs.

Note that Windows installations normally uses time ticks of 16-64 ms for
task scheduling. This means that when several threads runs at the same
priority, a round-robin scheduling results in non-sleeping threads to have
to wait for one or more full time slices before receiving CPU time again.
In short - unless every other thread in the machine is either most of the
time idling or running at lower priorities, a thread can not execute in
every time slice.

Animating symbols on screen is better handled at 5 Hz, i.e. 200 ms timer
ticks in the user interface (UI) thread. Actual data gathering should be
performed in a worker thread with suitable priority, unless the update
speed - and amount of work - is low enough that it can be done in a tick
handler without affecting performance of the application. Preferably, the
work thread should also regularly sleep - unless it will automatically
sleep while waiting for file or communications data. The only users who
accept a program running constantly at 100% are game players, scientists
and some R&D people.

An application that always run full-time is more or less unusable on a
laptop, even if the job is run at a lower priority. The cooling in laptops
isn't built for constant use at max CPU load because of the miniscule fans
and heatsinks. Even for office machines, the noise level will normally
increase significantly since power supply and processor fans will have to
run at elevated speeds.

In short: settle for 5 or possibly 10 Hz animation speed for the tick
data, and settle for maybe 1 or 2 Hz "game logic" speed. The users will
have a hard time trying to read the data and react to more than 2 or 3
changed numeric values anyway, so higher "game logic" speed will not allow
a stock trader to react any fster to an event. If this isn't a dedicated
machine running tick information at a stock exchange or similar, it might
even be enough to evaluate what data to display every 2-5 seconds, without
users noticing any slowness in the system.

The best kind of programs are the "invicible" programs. You get the
benefits of the program without really noticing that it is there. If it is
a desktop application, the only reason you should know that the
application is running is that you can read the output. As soon as a
program starts to consume enough CPU or memory resources to affect other
programs or responsiveness of the machine, people will start to dislike it
unless the machine is specifically bought for the job. A CAE system is
normally built specifically for the task, so people find it normal if it
takes minutes or hours to simulate accoustic behaviour in concert halls,
turbulence around wing tips of airplanes or if image processing of space
photos is run as non-interactive batch jobs.

/Per W

On Wed, 14 Jun 2006, Bin Zhou wrote:

>
> Thanks for the message. I do not think the feature was used correctly in our
> implementation. The system is a Win fat client to show stock tick data.
> Internally a data cache is used to store tick information for registered
> stock symbol. Once there is any tick data update, cached data will be
> updated. The timer is used by the user interface elements to read data again
> from the cache every 16 milliseconds. Also, some calculated results using
> the tick data will be published to message Q triggered at some intervals set
> through another timer event. Now I found the UI is extremely non-responsive.
> Clicking with mouse to select a UI element takes long time and during which
> the screen seems to be frozen. I think the design tried to avoid using
> multiple thread, but did not consider much on the impact flushing the timer
> with so high a frequent messages.
>
> Thanks,
>
> Bin
>
> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...]
> Sent: Wednesday, June 14, 2006 6:29 PM
> To: Bin Zhou
> Cc: dev...@li...
> Subject: Re: [Dev-C++] Using MFC Timer Framework
>
> You can't have events every 1 ms using the normal timers.
>
> The timer events does not stack but gets lost.
>
> Windows makes use of callbacks and messages to perform most of it's actions.
> The timers doesn't run in own threads.
>
> I don't know what you want to do, but windows is basically not designed to
> trigger actions every 1 ms. Some things - for example sound - may use
> hardware acceleration with buffering.
>
> One thing to look into a bit more are the multimedia timers available in
> Windows. They have better priority and granularity. However - don't abuse
> them. Make sure that the application really, really need high-speed timers
> before continuing with the coding!
>
> /Per W
>
> On Wed, 14 Jun 2006, Bin Zhou wrote:
>
> > Hi,
> >
> > I was just assigned to work on a MFC application using the MFC Timer
> > framework. Basically the application sets up several timer events. One
> > event is set to run every one millisecond. Because of the machine
> > constraints, it actually may get kicked off every 17 milliseconds if
> > no other things running. However, when some other operations of the
> > application are running, those other things may jump into the way. My
> questiona are:
> >
> > 1. whether each Timer event is set up to run in its own thread.
> > 2. if the timer triggered event takes longer to finish than the time
> > off value set, what will happen. Will those event be pilled up in the
> > message queue so that once the application gets a chance, it will go
> > back to pick them up.
> >
> > Thanks,
> >
> > Bin Zhou
>
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>