Apologies for the slow review here... On Thu, 2010-08-12 at 16:40 -0700, James Jones wrote:
> <para> > -The extension adds <function>Counter</function> and > -<function>Alarm</function> to the set of resources managed by the > +The extension adds <function>Counter</function>, <function>Alarm</function>, > +and <function>Fence</function> to the set of resources managed by the > server. A counter has a 64-bit integer value that may be increased or > decreased by client requests or by the server internally. A client can block > by sending an Await request that waits until one of a set of synchronization > -conditions, called TRIGGERs, becomes TRUE. > +conditions, called TRIGGERs, becomes TRUE. A fence has two possible states: > +triggered and not triggered. Client requests can put the fence in either of > +these states. A client can block until one of a set of fences becomes > +triggered by sending an AwaitFence request. > </para> I feel like this whole section wants a rewrite, since Alarms aren't discussed until much later. Would be worthwhile if doing so to note that Fences are explicitly bound to a screen (though I wouldn't insist on it to get this merged). And on that subject... > +<para> > +The <function>CreateFence</function> request allows a client to create a > +<function>Fence</function> that can be triggered and reset using > +<function>TriggerFence</function> and <function>ResetFence</function> > +requests, respectively. The <function>TriggerFence</function> request > changes > +the fence's state only after all previous rendering commands affecting > objects > +owned by the given fence's screen have completed. > +</para> I'm a little unclear on _why_ they're bound to screens. What semantics does that imply? The only reason I can imagine wanting to do so in the protocol is if the server itself would ever trigger a Fence on a Drawable, because then you'd need to wire the Fence to the right ScreenRec. But it seems like that should never happen for client-created Fences, only for server-created Fences. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
