Re: Alternative to Delay()
Re: Alternative to Delay()
- Subject: Re: Alternative to Delay()
- From: David Duncan <email@hidden>
- Date: Tue, 29 Jul 2003 17:03:14 -0400
However, despite the official documented recommendation, a loop calling
TrackMouseLocation is still not the nicest coding technique in terms of
multi-processing and user interaction. Such a loop simplifies the
programmers
job, but does not always use the CPU efficiently. As a rule, any time
the code
is looping while polling for a change in state, this code is wasting
some
amount of CPU.
TrackMouseLocation() doesn't poll a state. It blocks on the event loop
waiting for a particular class of events to arrive and reports those
events to the user. While it may use a small amount of time by passing
back events that the user isn't interested in, this hit is likely to be
taken by the process anyway because it is likely that the system would
have taken that event anyway.
The best multi-processing techniques are to write your code so that it
is
completely event driven and re-entrant. When you handle mouse down,
for
example, set some state variables and remember some coordinates and
then
return. Then, your application is not taking any CPU or executing any
instructions until the next event comes in. If the next event is a
mouse moved
event, your handler can use the state variables and starting mouse
position to
display any intermediate results, update appropriate state variables,
and
again return without looping. You will eventually receive a mouse up
event
which should signal the final result that the user's mouse drag gesture
indicates. By returning immediately after processing a single event,
you
guarantee that your app is not taking any more CPU than the absolute
minimum
needed.
I would say that this 3rd method is exactly equivalent to the 2nd
(TrackMouseLocation()) method, but by removing the loop construct
you've added overhead to deal with non-local variables. I would
consider the tradeoff to be moot, while the additional coding
complexity isn't.
Coding in this third method is not traditional Mac programming. It
also may
only be possible in Cocoa (I've never written a pure Carbon app).
And, most
important, many programmers have trouble organizing their code this
way without
the convenient localization of a loop. But it is the only way to be
totally
re-entrant and avoid excess CPU instructions that a looping construct
creates.
Fewer instructions means less CPU usage. Event loops are a crutch :-)
It is possible in Carbon, it's event model is just as rich as Cocoa's.
And fewer instructions don't necessarily make for less CPU usage - a
load/store instruction takes significantly longer to execute than a
compare and branch.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.