<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body><span class="vcard"><a href="page.cgi?id=describeuser.html&login=rstrode%40redhat.com" title="Ray Strode [halfline] <rstrode@redhat.com>"> <span class="fn">Ray Strode [halfline]</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - memory leak"
href="https://bugzilla.gnome.org/show_bug.cgi?id=761312">bug 761312</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Attachment #320235 is obsolete</td>
<td>
</td>
<td>1
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - memory leak"
href="https://bugzilla.gnome.org/show_bug.cgi?id=761312#c41">Comment # 41</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - memory leak"
href="https://bugzilla.gnome.org/show_bug.cgi?id=761312">bug 761312</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=rstrode%40redhat.com" title="Ray Strode [halfline] <rstrode@redhat.com>"> <span class="fn">Ray Strode [halfline]</span></a>
</span></b>
<pre>Created <span class=""><a href="attachment.cgi?id=320310&action=diff" name="attach_320310" title="wayland: stage uncommitted changes to dedicated buffer">attachment 320310</a> <a href="attachment.cgi?id=320310&action=edit" title="wayland: stage uncommitted changes to dedicated buffer">[details]</a></span> <a href='review?bug=761312&attachment=320310'>[review]</a>
wayland: stage uncommitted 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 committed 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, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed 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 back filling
that new buffer with a readback of the committed buffer.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>