When should a nested server first post a buffer?

[Alberto Aguirre]

"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 <
alan.griffiths at canonical.com> wrote:

>  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.
>
> --
> 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/20150528/1e6c8f9d/attachment.html>