[Mesa-dev] [PATCH 1/2] glx: Ensure that glXWaitX actually waits for X.

[Eric Anholt]

Fredrik Höglund <fredrik at kde.org> writes:

> On Tuesday 07 May 2013, Eric Anholt wrote:
>> Ever since fake front was introduced in
>> 63b51b5cf17ddde09b72a2811296f37b9a4c5ad2, we were skipping the XSync() in
>> the non-fake-front path, so compositors like Firefox's GL canvas were
>> having to manually put it in outside of glXWaitX().
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52930
>> ---
>>  src/glx/dri2_glx.c | 21 +++++++++++++++++----
>>  1 file changed, 17 insertions(+), 4 deletions(-)
>> 
>> diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
>> index 7ce5775..3cdd249 100644
>> --- a/src/glx/dri2_glx.c
>> +++ b/src/glx/dri2_glx.c
>> @@ -639,10 +639,23 @@ dri2_wait_x(struct glx_context *gc)
>>     struct dri2_drawable *priv = (struct dri2_drawable *)
>>        GetGLXDRIDrawable(gc->currentDpy, gc->currentDrawable);
>>  
>> -   if (priv == NULL || !priv->have_fake_front)
>> -      return;
>> -
>> -   dri2_copy_drawable(priv, DRI2BufferFakeFrontLeft, DRI2BufferFrontLeft);
>> +   if (priv != NULL && priv->have_fake_front) {
>> +      /* Ask the server to update our copy of the front buffer from the real
>> +       * front buffer.  This will round-trip with the server, so we can skip
>> +       * the XSync().
>> +       */
>> +      dri2_copy_drawable(priv, DRI2BufferFakeFrontLeft, DRI2BufferFrontLeft);
>> +   } else {
>> +      /* From the GLX 1.4 spec, page 33:
>> +       *
>> +       *     "X rendering calls made prior to glXWaitX are guaranteed to be
>> +       *      executed before OpenGL rendering calls made after
>> +       *      glXWaitX. While the same result can be achieved using XSync,
>> +       *      glXWaitX does not require a round trip to the server, and may
>> +       *      therefore be more efficient."
>> +       */
>> +      XSync(gc->currentDpy, False);
>
> I think this could be improved a bit by calling xcb_get_input_focus() followed
> by xcb_flush() here, and forcing the reply the next time the command buffer
> is about to be flushed.

That would require plumbing this bit of GLX down to the driver's
batchbuffer flushing, which is a fair chunk of work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130508/e3f47831/attachment.pgp>