[Wayland-bugs] [Bug 75303] Protocol: wl_buffer.release is racy

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75303

Kristian Høgsberg <krh at bitplanet.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #2 from Kristian Høgsberg <krh at bitplanet.net> ---
(In reply to comment #0)
> Consider a client doing this:
> 1. surface1.attach(buffer1)
> 2. surface1.commit
> 3. surface2.attach(buffer1)
> 4. surface2.commit
> 
> Then the client receives buffer1.release.
> 
> It is ambiguous, whether the release corresponds to step 2 or step 4. That
> is, the client cannot know if the latter commit still holds the buffer
> reserved in the server. The server may have had time to process and release
> the buffer before step 4, in which case the buffer would be reserved again
> after step 4.
> 
> The problem is the same also, if surface1 and surface2 were both just
> surface1. If the compositor has time to repaint in between the commits, the
> client may get a release it most likely interprets as the release
> corresponding to step 4, which would be wrong.
> 
> How should this be resolved?
> 
> A suggestion from Jason Ekstrand was to modify the protocol to guarantee one
> release event for each commit that makes the buffer reserved. This would
> allow clients to use simple reference counting.

We do that now.  Every attach+commit is followed by a release.  If a client
attaches a buffer to two surfaces, it needs to receive two release events
before it can use the buffer again without causing artifacts.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20140404/7b905e92/attachment.html>