libweston/compositor: Check whether flushing is allowed

This patch acts as bandaid in the core compositor to avoid the renderer
doing a flush after the buffer has been released. Flushing after release
can happen due to problems in the internal damage tracking, is violating
the protocol, and causes visible glitches.

A more proper fix would be to handle compositor side damage correctly.

Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Daniel Stone <daniel.stone@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
dev
Marius Vlad 2 years ago
parent 50f98b1006
commit 7fd22ae44d
  1. 16
      libweston/compositor.c

@ -2749,12 +2749,26 @@ weston_output_damage(struct weston_output *output)
weston_output_schedule_repaint(output);
}
/* FIXME: note that we don't flush any damage when the core wants us to
* do so as it will sometimes ask for a flush not necessarily at the
* right time.
*
* A (more) proper way is to handle correctly damage whenever there's
* compositor side damage. See the comment for weston_surface_damage().
*/
static bool
buffer_can_be_accessed_BANDAID_XXX(struct weston_buffer_reference buffer_ref)
{
return buffer_ref.type == BUFFER_MAY_BE_ACCESSED;
}
static void
surface_flush_damage(struct weston_surface *surface)
{
struct weston_buffer *buffer = surface->buffer_ref.buffer;
if (buffer && buffer->type == WESTON_BUFFER_SHM)
if (buffer->type == WESTON_BUFFER_SHM &&
buffer_can_be_accessed_BANDAID_XXX(surface->buffer_ref))
surface->compositor->renderer->flush_damage(surface, buffer);
if (pixman_region32_not_empty(&surface->damage))

Loading…
Cancel
Save