Subject: When should a nested server first post a buffer?

From: Alan Griffiths <[email-masked]>
Date: Thu, 28 May 2015 17:35:29 +0100

There's a comment in unity-system-compositor (src/window_manager.cpp)

    // We need to wait for the second frame before marking the session
    // as ready. The first frame posted from sessions is a blank frame.
    // TODO: Solve this issue at its root and remove this workaround

that led me to do some experimenting. And what I discovered is that a
nested server posts a frame when the first surface is *created*.

That is...

1. start a host session: sudo mir_demo_server --vt 2 --arw-file
2. Start a nested session that will be obvious: mir_demo_server
--host-socket /tmp/mir_socket --background-color purple
--custom-compositor adorning --window-manager tiling

    At this point vt2 will have a black display because the nested
    server has yet to post a buffer. (Although there's a titlebar
    visible for its window - which is wrong but not the issue I want to
    raise.)

3. Now create a surface but don't post a buffer: mir_demo_client_basic

    At this point the purple background from the nested server appears.
    (And yes, I checked it is the surface appearing that causes the
    post: "tiling" doesn't paint titlebar surfaces and sticking a
    sleep() after mir_surface_create() makes it clear this is the
    relevant call.)

This seems inconsistent. I could imagine it making sense to post a frame
when starting (but the above comment suggests this isn't desirable).

Since we don't post on startup we really ought to wait until we actually
have content from a client.

Any dissenting opinions?

(And yes, we will need an acceptance for the correct behavior - once
that is agreed.)

PS This also suggests we have unnecessary compositing cycles whenever
surfaces are created.

---

From: Gerry Boland <[email-masked]>
Date: Thu, 28 May 2015 17:44:10 +0100

> PS This also suggests we have unnecessary compositing cycles whenever
+1 on fixing this.

Could mir clients exhibit this issue too? I have seen something similar with Qt clients and qtmir.
-G

---

From: Alberto Aguirre <[email-masked]>
Date: Thu, 28 May 2015 12:30:58 -0500

"Since we don't post on startup we really ought to wait until we actually
have content from a client."

+1. Yes.

On Thu, May 28, 2015 at 11:35 AM, Alan Griffiths <
[email-masked]> wrote:

> --host-socket /tmp/mir_socket --background-color purple --custom-compositor
> adorning --window-manager tiling
>
> At this point vt2 will have a black display because the nested server has
> yet to post a buffer. (Although there's a titlebar visible for its window -
> which is wrong but not the issue I want to raise.)
>
>
> At this point the purple background from the nested server appears. (And
> yes, I checked it is the surface appearing that causes the post: "tiling"
> doesn't paint titlebar surfaces and sticking a sleep()
> after mir_surface_create() makes it clear this is the relevant call.)
>
>
> (And yes, we will need an acceptance for the correct behavior - once that
> is agreed.)
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 29 May 2015 09:00:08 +0800

I've experienced this for a long time when running mir_proving_server 
nested inside mir_demo_server_minimal. The screen doesn't go grey 
(nested server is drawn) until a client is started in the nested server.

I feel it's a reasonable side-effect of us not drawing any "shell" in 
demo servers. But there is also a reasonable argument that the 
background colour is the simplest form of a /shell/ and it should render 
immediately on start-up.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Fri, 29 May 2015 13:12:39 +1000

On Fri, May 29, 2015 at 2:35 AM, Alan Griffiths 
<[email-masked]> wrote:
> This seems inconsistent. I could imagine it making sense to post a 
> frame when starting (but the above comment suggests this isn't 
> desirable).
> 
> Since we don't post on startup we really ought to wait until we 
> actually have content from a client.

A nested server should post a frame as soon as it's got something to 
draw. For most servers that should happen at startup, because they're 
drawing a shell. Presumably Unity8 falls into this category?

For mir_demo_server_basic we probably shouldn't draw anything before 
the first client posts a buffer. For mir_demo_server we probably should 
at least draw a background on startup.

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 29 May 2015 11:26:24 +0800

Sorry for the confusion. Yes it's just a bug that needs fixing...

If one frame has been posted then you need to take it because you can 
never predict how long before a second one arrives, if at all.

On 29/05/15 11:12, Christopher James Halse Rogers wrote:
>>> At this point vt2 will have a black display because the nested server
>>> has yet to post a buffer. (Although there's a titlebar visible for
>>> its window - which is wrong but not the issue I want to raise.)
>>
>>> (And yes, I checked it is the surface appearing that causes the post:
>>> "tiling" doesn't paint titlebar surfaces and sticking a sleep() after
>>> mir_surface_create() makes it clear this is the relevant call.)
>>
> For mir_demo_server_basic we probably shouldn't draw anything before the
> first client posts a buffer. For mir_demo_server we probably should at
> least draw a background on startup.
>
>

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 01 Jun 2015 17:02:17 +0100

> never predict how long before a second one arrives, if at all.

For clarity there are multiple bugs:

/1/ We composite when a surface is created - this leads to a nested
server posting a buffer with no content.
/2/ USC throws a buffer away as a workaround. Throwing a buffer away is
also a bug.

Having looked at the LegacySceneChangeNotification code it is simple to
fix the specific case of composite when a surface is created. However,

/3/ there are a host of cases in LegacySurfaceChangeNotification where
we would composite unnecessarily for surfaces that are not visible. For
example, the mir_demo_client_basic example in the original post triggers
composition when a surface that has never posted and is not visible is
destroyed.

I'll MP some improvements to Legacy*ChangeNotification to address /1/
and /3/ and then remove the workaround from USC.

The only disagreement on this thread seems to be whether or not
mir_demo_server should clear the background when started. I propose to
take the easier approach of retaining the existing behaviour (of not).

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 02 Jun 2015 07:04:11 +1000

On Tue, Jun 2, 2015 at 2:02 AM, Alan Griffiths 
<[email-masked]> wrote:
> …
> mir_demo_server should clear the background when started. I propose 
> to take the easier approach of retaining the existing behaviour (of 
> not).

This is fine by me.

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 02 Jun 2015 12:08:11 +0100

> Could mir clients exhibit this issue too? I have seen something similar with Qt clients and qtmir.

Gerry, could you check in on this discussion
<https://code.launchpad.net/%7Ealan-griffiths/mir/only-visible-surfaces-change-scene/+merge/260746>
to see whether it could explain these cases? (And, hopefully, confirm
that the same fix would work for them.)