Single buffered clients (LP: #1194333)

[Cemil Azizoglu]

I can see the value during SoC bringups and such as an internal tool, but
I'm not sure as an "official" feature. Why would an actual client want to
do single-buffer rendering? Is it to save memory?

-C


On Tue, Apr 29, 2014 at 1:41 AM, Christopher James Halse Rogers <
chris at cooperteam.net> wrote:

>
>
> 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 :)
>
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140429/4f431857/attachment.html>