Question about linux-explicit-synchronization

[Daniel Stone]

On Mon, 18 Feb 2019 at 10:13, Scott Anderson
<scott.anderson at collabora.com> wrote:
> On 18/02/19 11:02 pm, Daniel Stone wrote:
> > Doing this gets _really_ tricky as you start considering things like
> > synchronised subsurfaces (which always seems to be the case), since
> > you have to make sure you're not presenting incoherent results. But
> > for unrelated surfaces, you can definitely delay presentation.
>
> Ok, cool. That actually answers a follow-up question I would've had.
> I've been looking at implementing this in wlroots, and subsurfaces
> certainly were a point I was wondering about.
>
> The case in particular would be:
> - Parent surface is "ready" (signaled fence or no fence)
> - Subsurface is synchronized and fence is not signaled
>
> The intuitive thing would be to delay the parent's content from being
> updated until the subsurface is ready, but the protocol itself is a bit
> underspecified when it comes to this.

Yeah, the protocol should be fixed then in order to be clear. With
implicit sync, the compositor commits the configuration anyway (GL or
KMS), then atomicity is ensured by the implementation waiting. The
intention for explicit sync is the same: the compositor ensures that
the configurations are coherent.

Subsurfaces are explicitly tethered together by specification, however
there's nothing in the spec which tethers presentation of separate
surface trees. Those are allowed to be desynchronised, and it was the
intent of this spec to allow that for separate window trees.

If you've got a good idea of some spec language that would help clear
this up for subsurface trees, I'm all ears.

Cheers,
Daniel