Guarantees of order of X events vs requests

[Eirik Byrkjeflot Anonsen]

Maarten Maathuis <madman2003 at gmail.com> writes:

> On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen
> <eirik at opera.com> wrote:
>> 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?)
>>
>>
>> Some specific questions:
>>
>> 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?
>>
>> (And I assume that "serial" is monotonically increasing, except on
>> wrap-arounds...)
>
> I think the ordering is kept for obvious reasons, but you don't know
> when you'll see the result.

X is required to produce the same result as if all requests were handled
strictly in-order, but the server can reorder requests as long as the
client doesn't notice the difference.  I'm not so sure the "serial"
member of events are included in the set of "observable effects", and
I'm even less sure that implementations have kept that in mind.

So can I be sure that an event will reflect the state resulting from
exactly the requests with request number "serial" and earlier having
been executed?


>> Context:
>>
>> 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.
>
> I think you are supposed to draw the entire area that is exposed. If
> that is too costly, maybe render to a backbuffer and copy to the
> window.
>
> Just my two cents.

I certainly intend to draw the entire area that is exposed (typically
from a back buffer, yes...).  The problem is, I don't know where in the
window that area is now.  The event only tells me which area of the
window was exposed at the time when the event was generated.  If one of
the XCopyArea requests are executed after that, then the invalid area
will move too.

eirik