<div dir="ltr"><div><div>Hello mir team,<br></div><br>In order to get the next buffer for the client, we currently have:<br><br>rpc next_buffer(SurfaceId) returns (Buffer);<br><br></div><div>which is problematic for me in working on [1] because this implicitly releases the buffer from the client side, whereas in working on that performance improvement, I have to send a fd back to the server. So I was thinking of adding an rpc method more like:<br>
<br>rpc exchange_buffer(Buffer) returns (Buffer);<br><br></div><div>This would be sufficient to pass the fd fence back, and the buffer id in the Buffer protocol message would be sufficient for the server to figure out which surface has sent back its buffer. (given the global buffer id's we're using)<br>
<br></div><div>This does not address the problem noted in:<br></div><div><a href="https://bugs.launchpad.net/mir/+bug/1253868" target="_blank">https://bugs.launchpad.net/mir/+bug/1253868</a><br><div>but I think that might be better addressed by having an exchange type rpc call (explicit or implicit) and negotiating/increasing how many buffers the client owns somehow else.<br>
</div><div>
<br></div><div>This seems like something that could have diverse opinions, so I'm hoping to get some input on the protocol change here first.<br><br>Thanks!<br>Kevin<br></div><div><br>[1]<br><a href="https://blueprints.launchpad.net/ubuntu/+spec/client-1410-mir-performance" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/client-1410-mir-performance</a> item:<br>
"[kdub] fencing improvements for clients add the ipc plumbing"<br>
</div></div></div>