Guarantees of order of X events vs requests

[Soeren Sandmann]

Eirik Byrkjeflot Anonsen <eirik at opera.com> writes:

> What guarantees does X give when it comes to the order of events
> generated in relation to processing of the requests sent by the client?
> 
> (Also, of course: To which degree does various implementations of X
> actually fulfill these guarantees?)

It would be a major bug if any X server didn't order events
correctly. It should be safe to rely on, though you mileage and level
of cynicism may vary.

> X events have a "serial" value.  I expect that any event delivered by X
> will reflect the state after the request number "serial" (and all
> preceding requests) have been processed.  Is this correct?
>
> Can I also assume that the X event will reflect the state before any
> requests with a later serial number is processed?

That is correct. The protocol spec says:

        Whether or not a server is implemented with internal
        concurrency, the overall effect must be as if individual
        requests are executed to completion in some serial order, and
        requests from a given connection must be executed in delivery
        order (that is, the total execution order is a shuffle of the
        individual streams). The execution of a request includes
        validating all arguments, collecting all data for any reply,
        and generating and queueing all required events.

> Given an application that frequently performs a sequence of XCopyArea()
> calls on the contents of a window.  When this application receives
> Expose events or GraphicsExpose events, it is necessary for the
> application to know exactly which XCopyArea calls have taken effect to
> be able to correctly calculate which area of the window has become
> invalid.

Right. GTK+ used to have (and likely still has) a scheme where a
CopyArea generates an internal record that a piece of the window has
moved at a certain serial number. These records are stored in a queue.

Then, when an expose arrives, entries in the queue with a serial
number before the expose are processed. If the area touched by the
record intersects the area exposed, the expose is treated as if it
exposed the region

    (original_rect - intersected_rectangle) + (translated intersected_rectangle)

Unless you have a similar mechanism, you will probably have to call
XSync() after each XCopyArea() to ensure that the copying and
associated exposes have been processed on the server, before procesing
any exposes.


Soren