xwayland-input: Fix a crasher for a race with the Wayland compositor

If something quickly maps and unmaps a window, then we'll immediately
create and destroy the Wayland surface that cooresponds to that
window. If our mouse pointer is over the window when the surface is
created, we'll receive a enter on the window.

Since resource creation and destruction is not synchronous, that
means that the compositor will queue up an event for a resource that's
eventually destroyed. On the client-side, when we receive this message,
we note that the resource isn't allocated, and get a NULL surface in our
enter handler. We immediately try to dereference this, and then crash.

This was caused by running gtkperf while moving the window a lot.

Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
xwayland: Implement throttling for surfaces based on the frame event

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.

Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
xwayland: Snap damage reports to the bounding box

Instead of sending every little rect.  Lets x11perf run to completion,
makes 'while true; do gtkperf -a; done' take longer to crash.

This is effectively a resend of the same logic against the old
xfree86+xwayland branch:

http://lists.x.org/archives/xorg-devel/2013-October/038453.html

Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>