Hi.
On 09/18/2017 12:18 PM, Keith Packard wrote:
Thomas Hellstrom <thellst...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
