On Tue, Dec 04, 2012 at 03:58:11PM +0200, Pekka Paalanen wrote: > The protocol does not require us to flush_damage() on wl_buffer > destruction. In fact, by the time the server receives this request, the > client may have already clobbered the buffer's storage, so we could be > reading undefined data. Instead, just forget about the buffer. The > protocol already says, that a client must not destroy a buffer that is > being read by the server, or the window contents become undefined. > > The practical reason for this change is that the following commit can > consolidate wl_buffer destruction listener handlers.
Yeah, I think that's fine. Before surface.commit, the semantics were that you could destroy a buffer right after attach, and the server would reference or copy the underlying pixels. But requiring the buffer to be valid until the release event is more well-defined. Kristian > Signed-off-by: Pekka Paalanen <[email protected]> > --- > src/compositor.c | 3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/src/compositor.c b/src/compositor.c > index 88a37f7..d80d929 100644 > --- a/src/compositor.c > +++ b/src/compositor.c > @@ -187,9 +187,6 @@ surface_handle_buffer_destroy(struct wl_listener > *listener, void *data) > container_of(listener, struct weston_surface, > buffer_destroy_listener); > > - if (es->buffer && wl_buffer_is_shm(es->buffer)) > - es->compositor->renderer->flush_damage(es); > - > es->buffer = NULL; > } > > -- > 1.7.8.6 > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
