Guarantees of order of X events vs requests

[Eirik Byrkjeflot Anonsen]

Soeren Sandmann <sandmann at daimi.au.dk> writes:

> 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.

I was sure I remembered something like that, but I wasn't sure of the
exact wording.  I did notice this in my copy of the protocol spec ("X
Version 11, Release 6.9/7.0"), though:

      [Almost all] core events [.. also contains the sequence number of
      ..] the last request issued by the client that was (or is
      currently being) processed by the server.

Which makes me worry a bit that there is a possible loophole for the
request with this particular sequence number to not be reflected in the
event...  (Though I suspect that's not the intended meaning of that
sentence.)

>> 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)

Yes, that was pretty much my plan.  (Well, entries with serial numbers
older than the expose event are discarded, and the expose event is
adjusted for all the remaining entries...)

> 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.

That was my conclusion, yes.  Thanks for validating my logic :)

eirik