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