[Mesa-dev] [PATCH] st/dri: Add an option to always request a front buffer from the loader

Thomas Hellstrom thellstrom at vmware.com
Mon Sep 18 20:06:20 UTC 2017


Hi.

On 09/18/2017 12:18 PM, Keith Packard wrote:
> Thomas Hellstrom <thellstrom at vmware.com> writes:
>
>> When an application decides to read from the front buffer of a window,
>> typically a fake front is created and initialized with the real front window
>> contents. However, if there was a window manager reparenting operation between
>> the last swapbuffer and the read the real front window contents would be
>> invalid. This hurts piglit applications that read from the front.
> What do you mean by 'invalid'? On a running desktop, reparenting is
> typically done before the window gets mapped, so there shouldn't be
> *anything* done to the window by this operation. If you restart the
> window manager, it will have to reparent all existing windows, which
> looks like an unmap followed by a map, but those operations all do well
> defined things to the window contents.
>
Hmm,

So what's happening (timing dependent) is that a window that's supposed 
to be all red after a swapbuffer instead has black borders at the bottom 
and to the right.
So my guess as to what was happening was the server executing the 
swapbuffer, then the window manager would reparent and draw window 
decorations.

But if that's not the case, any idea what might be causing this? It 
happens with both dri2 and dri3, more frequently with dri3.

/Thomas





More information about the mesa-dev mailing list