Messages in this thread | | | Date | Thu, 8 Jul 1999 22:22:59 +0200 | From | Jamie Lokier <> | Subject | Re: Important patch to fix select! |
| |
My credentials: I have written or modified several interactive games inside and outside X, on several Unix variants.
And one thing that showed up as a pain was the scheduling behaviour of select().
For 3d games, precise frame timing doesn't seem to matter. You just don't notice. For 2d, if there's only a few things moving you really notice the difference between "smooth" and "not smooth". Ie. visual jitter. I'm going to describe what I had to do to get "smooth" under SunOS 4.
Basically, to smoothly move an image across the screen at say 25Hz you have to do this:
time = gettimeofday(); while (1) { move_sprite_to_new_position(); flush_X_commands(); time = time + 1/frame_rate; select(0,0,0,0, new_time - gettimeofday() - SCHEDULER_TICK); while (gettimeofday() < new_time) { /* Busy wait for av. 0.5 ticks, and _don't_ yield. */ } }
The ugly part is the busy wait. No matter how little is being displayed, we have to spent xx% CPU time busy waiting just so we can display at the right times.
The xx% CPU is wasted even if we have other things to do like a sound mixer thread.
The other ugly part is SCHEDULER_TICK. It varies from system to system. Actually SCHEDULER_TICK can be estimated by measuring actual scheduling times, filtering the estimate, and staying a bit short because jitter tends to enlarge rather than reduce the time.
This is required if the machine is otherwise idle, or if it is busy.
This is required even though the scheduling timer is ticking 3-4 times faster than the frame rate, and even with communicating with the X server asynchronously and so on. (As long as there's not a lot moving and it's in 2d).
I haven't looked at those programs under Linux -- but from the discussion here it looks like Linux has a similar property: you have to select() and then do a busy wait. What a waste of CPU! We could be mixing sound in another thread during that time...
Obviously _I'd_ like a select() that waits exactly the right amount of time, and then the process wakes up and competes for scheduling. If the system is idle or the process has high priority, it _should_ get scheduled as soon as the time expires.
In other words, some acceptable version of the UTIME patch.
My humble opinion. It's less relevant these days as with 3d full screen updates you just don't notice the jitter any more.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |