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