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 benefit * 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
- Owen 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 > spending > > time on the extended version of the sync protocol and > > _NET_WM_FRAME_TIMINGS, because, to my knowledge, those are implemented > only > > by GTK+ 3, and most GTK+ 3 apps will be running as native Wayland apps. > On > > the other hand, gtk2 and qt4 X clients will be around to exercise the > basic > > 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. > > > Thanks, > pq >
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel