Guarantees of order of X events vs requests

[Maarten Maathuis]

On Wed, Oct 20, 2010 at 2:57 PM, Eirik Byrkjeflot Anonsen
<eirik at opera.com> wrote:
> 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.
>

You do know that regardless of how many operations are still
scheduled, your new one will end up at the end? So after all your
previous XCopyArea requests.

> eirik
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: madman2003 at gmail.com



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.