EWMH 1.6 with frame synchronization?

Jonas Ådahl jadahl at gmail.com
Fri Nov 25 08:19:55 UTC 2022


On Fri, Nov 25, 2022 at 03:18:36PM +0800, Po Lu wrote:
> Po Lu <luangruo at yahoo.com> 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


More information about the xdg mailing list