https://bugs.freedesktop.org/show_bug.cgi?id=88857
--- Comment #2 from Jonas Ådahl <[email protected]> --- Ah, right, the position should be considered part of the parents surface, true. The issue that exists is though that the protocol explicitly says "on wl_surface.commit", which is not necessarily the same time that the parent surface gets its content updated. AFAIU the content of a surface is applied either on - wl_surface.commit, - wl_subsurface.set_desync, or - when parent surface state is applied So if we have this "tree", with one toplevel surface with a single subsurface which itself has one single subsurface: T | s1 | s2 If the following flow happens: 1. s1::wl_subsurface.set_sync 2. s1::wl_surface.attach 3. s1::wl_surface.commit 4. s2::wl_subsurface.set_desync 5. s2::wl_subsurface.set_position 6. s2::wl_surface.attach 7. s2::wl_surface.commit 8. s1::wl_subsurface.set_desync 9. s1::wl_surface.attach 10. s1::wl_surface.commit According to the spec the contents of s1 and s2 would be applied at 8, but the position would be applied at 10, but if I understand you correctly, the intention is that both the position and both s1's and s2's content should be applied at 8. It can be observed by running the test case in https://bugzilla.gnome.org/show_bug.cgi?id=731494 on weston and mutter, and observe that they behave differently because of this detail. It could maybe be fixed by changing the protocol to no longer require an explicit parent commit, but just an "parent content applied", I think, but can we make such changes now? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
