As Keith says, we (in this case, not Keith, but my co-authors and
myself) designed XSync with the network in mind, and to avoid
both network and process scheduling latencies.
The model is that you can have a whole set of requests queued
(and transmitted to the server), blocked on a counter (the basic
abstraction). Basically, a request says: block this
connection until the counter gets to a specified value.
Docs are in the tree....
So when the counter (in this case, a vblank counter) increments,
the X server gets woken up, the X schedular sees that there was
a client blocked on that counter, and it can immediately execute
(one or more) request(s), already present in the input buffer of the X server.
You can also get informed the counter incremented by an event,
but that is slow: the event mechanism is mostly to (as in TCP) serve
as a clocking mechanism, so your application can know to get the next (set) of
requests to the X server for the next counter increment.
In this way, we can avoid network round trip times (and multi-process
scheduling latencies) and achieve very fine synchronization, either
between X clients or with external events (real time, or vertical sync).
All this was fully tested/debugged in the early '90's, when the UNIX
desktop died; it has been the lack of driver support that has held this
back.
- Jim
--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[EMAIL PROTECTED]
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
