Subject: Single buffered clients (LP: #1194333)

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 29 Apr 2014 06:07:45 +0010

We've got a bug filed¹ documenting that we don't support 
single-buffered clients. I'd like to mark this as WontFix.

The reasoning being: single buffered clients cannot reliably render 
without glitches, EGL allows us to not support frontbuffer rendering, 
and our current pseudo-support for single buffering results in the 
BufferBundle being more complex than it needs to be.

Since it doesn't work now, and cannot work well, I suggest we annotate 
the bug as such.

¹: https://bugs.launchpad.net/mir/+bug/1194333

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 29 Apr 2014 14:12:06 +0800

It does kind of work now, providing you honor the limitation of not 
producing and consuming at the same time. 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.

On 29/04/14 13:57, Christopher James Halse Rogers wrote:
> We've got a bug filed¹ documenting that we don't support single-buffered
> clients. I'd like to mark this as WontFix.
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 29 Apr 2014 06:50:06 +0010

On Tue, Apr 29, 2014 at 4:12 PM, Daniel van Vugt 
<[email-masked]> wrote:
> 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 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.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 29 Apr 2014 06:51:11 +0010

> 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 :)

---

From: Cemil Azizoglu <[email-masked]>
Date: Tue, 29 Apr 2014 09:07:41 -0500

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 <
[email-masked]> wrote:

>
>
> On Tue, Apr 29, 2014 at 4:40 PM, Christopher James Halse Rogers <
> [email-masked]> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 4:12 PM, Daniel van Vugt <
>> [email-masked]> wrote:
>> > It does kind of work now, providing you honor the limitation of not >
>> ‘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 >
>> > > I would rather just implement it. It's trivial to implement and >
>> maintain.
>>
>> 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.
>>
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 30 Apr 2014 07:30:46 +0010

For those playing at home, there's further discussion on 
https://code.launchpad.net/~vanvugt/mir/single-buffer/+merge/217555