On 28/05/15 17:35, Alan Griffiths 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. > > +1 on fixing this.
Could mir clients exhibit this issue too? I have seen something similar with Qt clients and qtmir. -G -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
