<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 - GtkRevealer: reveal-child should avoid changing child allocation during animation"
href="https://bugzilla.gnome.org/show_bug.cgi?id=763350">bug 763350</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;">CC</td>
<td>
</td>
<td>jadahl@gmail.com, rob@robster.org.uk, wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<td style="text-align:right;">Component</td>
<td>.General
</td>
<td>Backend: Wayland
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - GtkRevealer: reveal-child should avoid changing child allocation during animation"
href="https://bugzilla.gnome.org/show_bug.cgi?id=763350#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - GtkRevealer: reveal-child should avoid changing child allocation during animation"
href="https://bugzilla.gnome.org/show_bug.cgi?id=763350">bug 763350</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>so the obvious thing I didn't piece together yesterday was we aren't actually
resizing the window, just things in the window. So, in theory we should be able
to reuse the surface buffer and avoid allocating a new one. The fact that we
aren't reusing the buffer is worth investigating.
It could be we're drawing before the compositor is done with the buffer, so
we're having to allocate a new buffer to accommodate out of band drawing. If
that's the case, maybe we can stop doing that.
If allocating the extra buffer / cairo surface is hard to prevent, one easy fix
might be to allocate it up front. We aren't changing the size of the window,
after all. Then if we end up needing the second buffer, it will only need to
page fault into the compositor the first time it's used, and not the subsequent
times its reused.
A more involved fix, would entail breaking our 1-to-1 relationship between
wl_shm_pool objects (mmapped regions) and wl_buffer objects (sub buffers in
those regions). Right now we allocate a pool the size of the buffer we need,
and then allocate exactly one buffer from the pool. Instead, we could allocate
a bigger pool up front and always source new buffers from that pool. So the
pool would stick around but buffers would be transient. We'd probably need a
new heap data structure to do the management of buffers from the pool. We
could be smart about when the window shrinks, too, and continue to use buffers
from the same pool. Of course if the window gets bigger we'd either have to
allocate a new pool or resize the existing pool.</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>