This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/real-browser
in repository enlightenment.
View the commit online.
commit 0d44cc4493241683d0a83257d4292f5f0a1567a7
Author: Cedric BAIL <[email protected]>
AuthorDate: Mon Aug 17 00:45:14 2026 -0600
e_pixmap - a buffer taken off the busy list still has to go back to the client
Chromium and Brave froze maximised about half the time. The window would be
told to unmaximise, receive the configure, recompute its minimum size, and then
go silent - nothing but xdg_wm_base pings for the next thirty seconds. Firefox
never did it, which is the clue: Firefox has its own timers, and Chromium draws
only when it has a buffer to draw into.
E never gave it one. Three e_pixmap_resource_set calls in a session and not a
single wl_buffer.release sent.
_e_pixmap_wayland_image_clear emptied cp->busy_list by decrementing busy by
hand:
EINA_LIST_FREE(cp->busy_list, buffer)
{
buffer->busy--;
if (buffer->dmabuf_buffer) linux_dmabuf_buffer_unref(...);
}
A buffer whose count reached zero there was finished with and never handed
back, because the one place that sends wl_buffer.release is the function this
does not call. The client then waits for a buffer it will not get, cannot
draw, and therefore cannot ack the configure it was sent - which from the
compositor's side looks like a browser ignoring window management.
_e_pixmap_wl_resource_release does the same decrement and the same dmabuf
unref, and sends the release at zero. Use it.
This is why the browser tests were flaky rather than failing: the test suite
polls by round-tripping through the compositor, which pushed E's main loop
along and got a render - and a release - out of it by luck. Slowing the polling
down made the failure certain, which is what pointed here.
Measured, five runs each after this and nine before it in a different order:
Firefox 5/5, Chromium 5/5, Brave 5/5, no cores, twenty-four consecutive clean
runs across the three. Before: roughly half. wl-globals, all eleven protocol
tests and e_wlcs_driver pass.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---
src/bin/e_pixmap.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
index 17edfe779..e490f65c5 100644
--- a/src/bin/e_pixmap.c
+++ b/src/bin/e_pixmap.c
@@ -300,12 +300,19 @@ _e_pixmap_wayland_image_clear(E_Pixmap *cp)
{
E_Comp_Wl_Buffer *buffer;
+ /* Through the release path, not by hand. This used to decrement busy
+ * itself, so a buffer that reached zero here was finished with and
+ * never handed back: no wl_buffer.release was sent, ever. A client
+ * that needs that buffer to draw the next frame then waits for it
+ * forever - and a client that cannot draw cannot ack a configure, so
+ * from the compositor's side it looks like a browser refusing to come
+ * back from maximised. Measured on Brave: three e_pixmap_resource_set
+ * calls, zero releases sent, and a window stuck maximised.
+ *
+ * _e_pixmap_wl_resource_release does the same decrement and the same
+ * dmabuf unref, and sends the release when the count reaches zero. */
EINA_LIST_FREE(cp->busy_list, buffer)
- {
- buffer->busy--;
- if (buffer->dmabuf_buffer)
- linux_dmabuf_buffer_unref(buffer->dmabuf_buffer);
- }
+ _e_pixmap_wl_resource_release(buffer);
}
if (!cp->held_buffer) return;
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
