After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761733 - wayland: drawing artifacts as a result of incorrect use of shm_surface busy state
wayland: drawing artifacts as a result of incorrect use of shm_surface busy s...
Status: RESOLVED DUPLICATE of bug 761312
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-02-08 21:56 UTC by David Reveman
Modified: 2016-02-09 02:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Reveman 2016-02-08 21:56:44 UTC
Gdk's wayland backend attempts to use the "busy" state of the shm_surface to determine if a blit is needed or if the buffer can be updated directly. This is broken as by committing a buffer that is currently busy you lose track of when the buffer is actually released.

Example:

1. gdk creates buffer [gdk-state:not-busy][actual-state:not-busy]
2. gdk updates buffer WITHOUT blit
3. gdk commits and marks buffer as busy [gdk-state:busy][actual-state:busy]
4. compositor is done with buffer and sends a release event to gdk [gdk-state:busy][actual-state:not-busy]
5. gdk updates buffer WITH blit as it's still seen as busy before the release event as been processed
6. gdk commits and marks buffer as busy [gdk-state:busy][actual-state:busy]
7. gdk receives/processes the release event from the previous commit [gdk-state:not-busy][actual-state:busy] (BAD)
8. gdk updates buffer WITHOUT blit as from gdk's pov it's not busy (BAD)

This can result in drawing artifacts as the compositor might use the buffer at the same time as gdk is updating it.
Comment 1 David Reveman 2016-02-09 01:15:21 UTC
This is related to https://bugs.freedesktop.org/show_bug.cgi?id=75303
Comment 2 Jonas Ådahl 2016-02-09 01:48:14 UTC
Hey. Yes, the buffer reusing was broken (it could also leak buffers), but it was recently fixed by bug 761312 which got rid of the busy flag completely. A buffer is now only-reused if a wl_buffer.release is received before painting the next frame, which should be the common case if the compositor creates a GL texture from the buffer right after it being committed. In other cases new buffers are always created and old ones destroyed when released. This could of course be improved later by keeping track of more buffers, but at least we should behave correctly now.

So, marking this as a duplicate. Please re-open if you think the issue is still present.

*** This bug has been marked as a duplicate of bug 761312 ***
Comment 3 David Reveman 2016-02-09 02:46:48 UTC
Sounds good. I just verified that ToT works as I'd expect. Thanks!