would work I guess. Clients are supposed to throttle using the bread
crumb events, so we shouldn't get into this situation.
+Throttling/scheduling - there is currently no mechanism for scheduling
+clients to prevent greedy clients from spamming the server and
+starving other clients. On the other hand, now that recompositing is
+done in the idle handler (and eventually at vertical retrace time),
+there's nothing a client can do to hog the server. Unless we include
+a copyregion type request, to let a client update it's surface
+contents by asking the server to atomically copy a region from some
+other buffer to the surface buffer.
+
+Atomicity - we have the map and the attach requests which sometimes
+will have to be executed atomically. Moving the window is done using
+the map request and will not involve an attach requet. Updating the
+window contents will use an attach request but no map. Resizing,
+however, will use both and in that case must be executed atomically.
+One way to do this is to have the server always batch up requests and
+then introduce a kind of "commit" request, which will push the batched
+changes into effect. This is easier than it sounds, since we only
+have to remember the most recent map and most recent attach. The
+commit request will generate an corresponding commit event once the
+committed changes become visible on screen. The client can provide a
+bread-crumb id in the commit request, which will be sent back in the
+commit event.
+
+ - is batching+commit per client or per surface? Much more convenient
+ if per-client, since a client can batch up a bunch of stuff and get
+ atomic updates to multiple windows. Also nice to only get one
+ commit event for changes to a bunch of windows. Is a little more
+ tricky server-side, since we now have to keep a list of windows
+ with pending changes in the wl_client struct.
+
+ - batching+commit also lets a client reuse parts of the surface
+ buffer without allocating a new full-size back buffer. For
+ scrolling, for example, the client can render just the newly
+ exposed part of the page to a smaller temporary buffer, then issue
+ a copy request to copy the preserved part of the page up, and the
+ new part of the page into the exposed area.
+
+ - This does let a client batch up an unctrolled amount of copy
+ requests that the server has to execute when it gets the commit
+ request. This could potentially lock up the server for a while,
+ leading to lost frames. Should never cause tearing though, we're
+ changing the surface contents, not the server back buffer which is
+ what is scheduled for blitting at vsync time.
+
RMI