We currently track whether or not a buffer can be released early
by looking at the copied_data boolean on the buffer. This boolean
is, practically speaking, always set to TRUE for shm buffers and is
always false otherwise.
We can just as easily check if the buffer is a shm buffer to decide
whether or not to do an early release. That's better from a
theoretical point of view since copied_data assumes a 1-to-1
relationship between surface and buffer, which may not actually hold.
This commit drops copied_data and changes the check to instead see
if the buffer is shm.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
commit 0165cb6974 changed
mutter to release committed shm buffers as soon as they were
uploaded to the GPU.
It also inadvertently changed mutter to prematurely
release EGL buffers (which never get copied, but get used
directly).
This commit corrects that mistake.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
When a client is ready for the compositor to read a surface's
shared memory buffer, it tells the compositor via
wl_surface_commit.
From that point forward, the baton is given to the compositor:
it knows it can read the buffer without worring about the client
making changes out from under it.
After the compositor has uploaded the pixel contents to the video
card it is supposed to release the buffer back to the client so that
the client can reuse it for future use.
At the moment, mutter only releases the buffer when a new buffer
is attached. This is problematic, since it means the client has
to have a second buffer prepared before the compositor gives the
first one back. Preparing the second buffer potentially involves
copying megabytes of pixel data, so that's suboptimal, and there's
no reason mutter couldn't release the buffer earlier.
This commit changes mutter to release a surface's buffer as soon
as it's done processing the commit request.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
