Single buffered clients (LP: #1194333)

Christopher James Halse Rogers chris at cooperteam.net
Tue Apr 29 06:41:11 UTC 2014



On Tue, Apr 29, 2014 at 4:40 PM, Christopher James Halse Rogers 
<chris at cooperteam.net> wrote:
> 
> 
> On Tue, Apr 29, 2014 at 4:12 PM, Daniel van Vugt 
> <daniel.van.vugt at canonical.com> wrote:
> > It does kind of work now, providing you honor the limitation of not 
> > producing and consuming at the same time.
> 
> And how do you honour that limitation? By ‘consuming’ here you 
> mean 
> ‘compositing’, right? Your global framerate is then limited to 
> the 
> slowest client - and a client can just plain freeze the compositor by 
> not releasing its buffer.
> 
> Of course, at the moment none of this works because there's no client 
> API for such cooperative rendering.
> 
> >  And it can easily be fixed to work adequately (e.g. for dumb 
> clients 
> > like mir_demo_client_fingerpaint or static raster image windows).
> > 
> > I would rather just implement it. It's trivial to implement and 
> > maintain.
> 
> I think it's neither trivial to implement nor to maintain. On the 
> implementation side you get to add some IPC, which is always fun, and 
> on the maintenance side it breaks one of the core promises of 
> BufferBundle - that a compositor can always acquire a buffer -*and* 
> the 
> Mir client API promise that getting your current buffer is free.

I could be convinced that it's possible by a sufficiently simple 
implementation, of course :)




More information about the Mir-devel mailing list