n-buffering and client behaviour

[Christopher James Halse Rogers]

I dislike that <shift>+<enter> is send.

On Tue, 2013-04-23 at 15:41 +1000, Christopher James Halse Rogers wrote:
> Hey all.
> 
> While I'm shepherding various Mesa patches upstream
… I'll use the time in-between review cycles to implement triple
buffering in order to implement eglSwapInteral(0) so that our benchmarks
are less useless.

There are two broad approaches here: the client always has exactly one
buffer, or the client library potentially has more than one buffer.

In the former the server sends a single buffer on surface creation and
in response to each next_buffer() request, but internally keeps
n-buffers available and coordinates handing off buffers to the
compositor component and the client library. The server is responsible
for determining whether next_buffer() should block or not.

In the latter case the server hands out two buffers on surface creation
and a single buffer in response to next_buffer(). The client library
then determines whether next_buffer() blocks.

The latter case allows eglSwapInterval(0) to not hit IPC for each frame,
which will result in higher benchmark numbers, but for regular clients
the IPC overhead should not be anywhere near the same proportion of
rendering time, so IPC-per-frame might generate more realistic numbers.

I'm therefore leaning towards the former approach - the client always
has exactly one buffer, and needs to round-trip to the server each
frame, even with eglSwapInterval(0).

Thoughts?