OK, it turns out Mir does correctly render a frame (or three!) immediately as soon as the compositor is restarted. The problem then is in unity-mir failing to stop/restart the compositor.
unity-mir assumes that turning the screen on is enough. Actually, it appears to not be enough. You have to stop/start the compositor _as_well_as_ turning screens on and off.
An example of how to do this is in Mir:
examples/demo-shell/window_manager.cpp
And it appears the code that needs fixing is in unity-mir:
src/unity-mir/dbusscreen.cpp
You need to remember to compositor->stop() and compositor-start(). And redraws will be scheduled immediately upon the call to start().
I think the reason why Mir doesn't do it automatically is because Mir has to consider and support multiple displays simultaneously. Just because you're turning one display off doesn't necessarily mean all compositing should stop in all use-cases. But for Unity8 on a touch device, it probably should.
OK, it turns out Mir does correctly render a frame (or three!) immediately as soon as the compositor is restarted. The problem then is in unity-mir failing to stop/restart the compositor.
unity-mir assumes that turning the screen on is enough. Actually, it appears to not be enough. You have to stop/start the compositor _as_well_as_ turning screens on and off.
An example of how to do this is in Mir: demo-shell/ window_ manager. cpp
examples/
And it appears the code that needs fixing is in unity-mir: unity-mir/ dbusscreen. cpp
src/
You need to remember to compositor->stop() and compositor-start(). And redraws will be scheduled immediately upon the call to start().
I think the reason why Mir doesn't do it automatically is because Mir has to consider and support multiple displays simultaneously. Just because you're turning one display off doesn't necessarily mean all compositing should stop in all use-cases. But for Unity8 on a touch device, it probably should.