Re: EWMH 1.6 with frame synchronization?
Jonas Ådahl writes: > I understand that, but at least you can point at the fact that it has > been implemented and used in GNOME for more or less a decade already. Well, that apparently does not hold water in the world of the KWin developers, who say: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg672095.html Specifically: > We are not introducing big changes into X11 at this time especially > for something non standard.
Re: EWMH 1.6 with frame synchronization?
Jonas Ådahl writes: > Perhaps open a merge request adding it to > https://gitlab.freedesktop.org/xdg/xdg-specs/-/blob/master/wm-spec/wm-spec.xml, > but you should probably familiarize with what happened the last time it > was attempted, which was in 2011: > > https://mail.gnome.org/archives/wm-spec-list/2011-October/msg6.html AFAICT from that discussion, the effort just fizzled out. The main/only problem with the approach you outlined is that I don't have a gitlab.freedesktop.org account, and the lawyers at my organization are not keen to let me get one. If I were to add the clarifications to the monotonic clock handling and send you a patch to wm-spec.xml, could you please open a merge request on my behalf? > But you can just as well go and implement it anyway, if you need this > kind of frame synchronization on X11; it's unrealistic that adding it to > wm-spec.xml would mean any changes were to be made to it anyway. It'd really be easier for me to work on this if it were in the wm-spec. That way, I could point and say "that's a standard!", instead of "that's floating somewhere in a bowl of fish soup!" Thanks.
Re: EWMH 1.6 with frame synchronization?
Jonas Ådahl writes: > 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. Yes, that's what I said ought to be clarified. I'm sorry I wasn't too clear there. So aside from that, what else is preventing the protocol from being included in the wm-spec? And how can I help get it included? Thanks a lot in advance.
Re: EWMH 1.6 with frame synchronization?
Po Lu 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.
EWMH 1.6 with frame synchronization?
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.
