<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - memory leak" href="https://bugzilla.gnome.org/show_bug.cgi?id=761312#c7">Comment # 7</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 <a href="page.cgi?id=describeuser.html&login=rstrode%40redhat.com" title="Ray Strode [halfline] <rstrode@redhat.com>"> Ray Strode [halfline]</a> <pre>Created <a href="attachment.cgi?id=320152&action=diff" name="attach_320152" title="wayland: release buffer after processing commit">attachment 320152</a> <a href="attachment.cgi?id=320152&action=edit" title="wayland: release buffer after processing commit">[details]</a> <a href='review?bug=761312&attachment=320152'>[review]</a> wayland: release buffer after processing commit 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>