When should a nested server first post a buffer?
Alan Griffiths
alan.griffiths at canonical.com
Thu May 28 16:35:29 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150528/8ce5022e/attachment.html>
More information about the Mir-devel
mailing list