Re: EWMH 1.6 with frame synchronization?

Jonas Ã…dahl <[email protected]> Fri, 25 Nov 2022 09:19:55 +0100
Newsgroups gmane.linux.xdg.devel
Message-ID <[email protected]>
On Fri, Nov 25, 2022 at 03:18:36PM +0800, Po Lu wrote:
> Po Lu <[email protected]> writes:
> 
> > Owen Taylor has a frame synchronization protocol for compositing
> > managers: https://fishsoup.net/misc/wm-spec-synchronization.html.
> >
> > It is currently only supported by Mutter and cannot be found outside his
> > blog.  Present does not quite work for this purpose, as the "present
> > redirection" code was never finalized.  Is anyone interested in
> > releasing a new version of the wm-spec with the frame synchronization
> > protocol?  I'd be more comfortable writing code to use it, and maybe
> > implementing it in more compositors, if it was specified in the actual
> > wm-spec.
> >
> > Thanks.
> 
> One clarification in the protocol I'd like to see is for the behavior
> when the X server time overflows to be clarified.  Right now, Mutter
> simply uses the X server time to generate the millisecond part of
> high-precision timestamps when the overflow happens, so that is what X
> clients expect.  I think the protocol should be clarified along those
> lines as well.

It's already relatively clearly specified, even with simple formula
illustrating how the timestamps look:

> For timestamps, the timestamp has the form (x_server_timestamp) * 1000
> + microsecond_value.

That leaves little room for interpretation. What could be improved is
the following part:

> In this case, high precision times can be generated directly, and two
> clients such will be able to exchange timestamps with sub-millisecond
> accuracy.

The confusion is that the timestamps can't be generated "directly" but
must still wrap in the same way X server timestamps. In other words,
it's fine to source your timestamps directly from the monotonic clock,
if it's concluded that the X server uses it, but you must still make
sure you wrap the values as if the milli second part is encoded using a
unsigned 32 bit integer. Mutter got this wrong in the past, and it
results in wierd bugs with frozen GTK frame clocks after almost two
months of uptime.


Jonas