On Wed, Jul 2, 2014 at 2:33 PM, Adam Jackson <[email protected]> wrote: > On Mon, 2014-06-30 at 20:29 -0400, Jasper St. Pierre wrote: > > This implements simple throttling that keeps us to one attach per > > frame. There isn't really an active performance benefit, since the > > buffers will be redrawn only once per frame anyway, but it does cut down > > on the chatty network traffic. Since the Wayland sockets might fill > > up as well, the cut down on the volume of data we send out also provides > > us with a big stability benefit. > > > > Namely, mutter is a lot more stable running gtkperf, a fairly intensive > > X11 application, after this change. > > Not really, no. Either with or without this change my gnome-on-wayland > session doesn't survive more than about three consecutive gtkperfs > before falling over. (The difference between our scenarios, I suspect, > being that you have an extra moving part in that you're running mutter > --wayland under an existing X session where I'm running gnome-shell > --wayland _as_ my session.) >
I was running it natively and couldn't get it to fall down. Hm. > The issue with this patch, I think, is that instead of drowning the > wayland server with attaches, we're drowning it in create/destroy pairs > when gtkperf hits the popup tests. Which means we actually want to > defer _all_ window surface activity to the frame event, so that when > popups live less than a frame time they never even reach xwayland. > That makes a lot more sense, because MapRequest is really the only place where we're making a synchronous request to the X server as part of XGetWindowAttributes. We should implement throttling in X11 for that as well, and I'd be fine with it, but after talking to Owen a bit more about it, I think we should probably just go and implement a better buffering approach inside libwayland-client so that if we ever get EAGAIN when trying to write to the pipe, we just allocate more data in the internal buffer. > - ajax > > -- Jasper
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
