[PATCH 2/2] xwayland: Implement throttling for surfaces based on the frame event

[Jasper St. Pierre]

On Wed, Jul 2, 2014 at 2:33 PM, Adam Jackson <ajax at nwnk.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140702/f6989a2e/attachment.html>