<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - subsurface protocol is inconsistent regarding immediate commit vs deferred commit"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=88857#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - subsurface protocol is inconsistent regarding immediate commit vs deferred commit"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=88857">bug 88857</a>
              from <span class="vcard"><a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> <span class="fn">Pekka Paalanen</span></a>
</span></b>
        <pre>(In reply to Jonas Ã…dahl from <a href="show_bug.cgi?id=88857#c2">comment #2</a>)
<span class="quote">> Ah, right, the position should be considered part of the parents surface,</span >
...
<span class="quote">> 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?</span >

My intention was that parent content updates include the sub-surface's position
change, which means that "both ... applied at 8" is the intended behaviour.
Weston's implementation works that way, doesn't it?

Requests s1::wl_surface.attach and s2::wl_subsurface.set_position are logically
part of the same state update for s1. Your example sequence confuses that when
the grouping implies that s2::wl_subsurface.set_position would be related to
s2::wl_surface requests.

In other words, analogous to the Wayland paradigm that a client cannot know the
absolute position of its windows, the code driving updates to s2 does not know
and does not control where the s2 surface appears. It may not even know it is a
sub-surface. The one who positions the s2 surface is the code driving the s1
surface: the same code that drives s1::wl_surface requests drives also
s2::wl_subsurface requests.

As to which way to correct the things, I suppose that depends on how much would
break because of the changes. Naturally I'd like it to be what I intended,
because that's the case I have thought out. The other way is unfamiliar to me
and would need thinking to see if it can work.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>