Probably a combination of factors:
* It never got into the official spec (I didn't want to push it in without
some review and hopefully a second implementation)
* It requires coordinated window manager and toolkit changes to get any
* The original spec fixed a huge problem with opaque resizing where the
application could lag arbitrarily behind the window manager - the extended
spec just makes things look better when you look close.
* People who really care about these things were already beginning to put
their efforts into Wayland
On Thu, Dec 1, 2016 at 4:53 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 30 Nov 2016 15:12:54 -0500
> Owen Taylor <otay...@fishsoup.net> wrote:
> > Hi Pekka,
> > I don't have a lot of of commentary to add here. Certainly getting the
> > frame-sync protocols right does require integration between Xwayland and
> > the compositing manager. I don't think there's that much virtue in
> > time on the extended version of the sync protocol and
> > _NET_WM_FRAME_TIMINGS, because, to my knowledge, those are implemented
> > by GTK+ 3, and most GTK+ 3 apps will be running as native Wayland apps.
> > the other hand, gtk2 and qt4 X clients will be around to exercise the
> > version of the protocol for the forseeable future.
> Hi Owen,
> that's valuable, saves me the effort of designing for and maybe
> implementing the extended version. :-)
> I'm kind of curious though why no other toolkit saw the benefit of the
> extended sync protocol.
email@example.com: X.Org development