On Wed, Oct 20, 2010 at 2:57 PM, Eirik Byrkjeflot Anonsen <[email protected]> wrote: > Maarten Maathuis <[email protected]> writes: > >> On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen >> <[email protected]> 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 > _______________________________________________ > [email protected]: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: [email protected] -- 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. _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
