Re: Problems with fast timeouts

[Paul Davis <paul linuxaudiosystems com>]

>> It's a simulator of a measuring device where the sampling rate is fixed at 2
>00Hz.
> > 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.

there's an even deeper reason than this. on 95% of all the display
hardware your program might conceivably run on, the display hardware
(the screen) only updates the screen 60-85 times a second. even if the
OS provided you with finer resolution for timeout scheduling it will
make *absolutely no difference* to what appears on the screen.

i generally use a 1/100 second timeout for the screen updates of my
realtime software. the GUI thread doesn't have real time scheduling,
so this timeout is not honored precisely, but we get it close enough
that things are close to the refresh rate of the screen. when the
kernel standard moves to HZ=1000 with the release of 2.6, asking for a
timeout of 1/80 second will be child's play, and will do this even
better. 

it would be nice if XFree86 was hooked into the refresh cycle of the
screen hardware, so that we could avoid tearing and other visual
effects caused by blitting the framebuffer in the middle of a hardware
redraw; i think i remember hearing that there was some work going on
to accomplish this.

--p