From 19a0ac25b9d356ade2bc3bef6e1bcb0cb8626f00 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Kristian=20H=C3=B8gsberg?= Date: Sat, 11 Oct 2008 19:40:01 -0400 Subject: [PATCH] Add notes on throttling, scheduling and atomicity. --- NOTES | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/NOTES b/NOTES index ced5835..61ee877 100644 --- a/NOTES +++ b/NOTES @@ -64,6 +64,50 @@ What to do when protocol out buffer fills up? Just block on write 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 -- 2.7.4