Re: Problems with fast timeouts
- From: Guido Draheim <guidod-2003- gmx de>
- To: Krzysztof Dubowik <kite interia pl>
- Cc: gtk-list gnome org
- Subject: Re: Problems with fast timeouts
- Date: Sat, 11 Jan 2003 14:19:07 +0100
Krzysztof Dubowik schrieb:
Hi,
I wanted my timeout function to be called 200 times per second.
> Another words, my timeout function to be called every 5 miliseconds.
why? what's the actual problem behind it?
It's a simulator of a measuring device where the sampling rate is fixed at 200Hz.
> I want to draw the graph at "real-time" - 1 pixel per 5ms.
Well, Krisz, there is no realtime anyway. The x11 display system is
strictly decoupled from your program, draw requests will not draw
on the screen but they result in a draw-message that will be sent
on to an interprocess message-queue. At some pointer later, the
x11 server will check the message-queue, and possibly multiple
draw requests are executed in the cpu execution cycle.
The visual update would get deterioted even more when the
client and server are on different machines, which is nothing
unusual in the x11 world. The attempt of being close to
"real time" is quite futile in this respect.
As a conclusion, there is nothing wrong when your program goes
through multiple update-cycles and pushes them as draw-requests
to the x11 server message queue. That might need you to
reorganize your sourcecode - instead of handling one update
cycle per timeout callback, you do check the actual clock time
and decide how many update cycles should be handled. That will
ensure one pixel to be drawn, and it will ensure the display
be visual screen strictly correlated to the real clock time.
That is needed for another reason as well, since it might
happen that there are other processes in the system that
consume cpu time and which have higher priority (!!) than
yours. That can starve your process for some time, and you
should ensure to get back into sync with wall time pretty
soon when your process will have a chance to run again.
I do not know your background, Krisz, but this is pretty
much a homework lesson done on realtime university courses.
Forgive me when being wrong, but you should redesign your
program concept anyway to match your desired goal - it is
wrong from the start.
-- cheers, guido counter.li.org #81555
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]