[Wayland-bugs] [Bug 761312] memory leak

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761312

Ray Strode [halfline] <rstrode at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #320043|0                           |1
        is obsolete|                            |

--- Comment #8 from Ray Strode [halfline] <rstrode at redhat.com> ---
Created attachment 320153
  --> https://bugzilla.gnome.org/attachment.cgi?id=320153&action=edit
wayland: stage uncommited changes to dedicated buffer

Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing commited updates: we
can't change what the compositor is actively processing.

The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later.  The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.

In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer.  The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again.  If the client needs to stage new updates, it allocates a
brand new staging buffer initialized with a copy of the contents from the
committed buffer.

As an optimization, the compositor has the option of releasing the
commited buffer back to the client.  If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates.  This optimization prevents having to allocate
a new staging buffer and the associated cost of initializing
that new buffer with a readback of the committed buffer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20160131/c9fe59ab/attachment.html>