Comment 6 for bug 1340510

Further investigation has confirmed that a stale frame issue exists *in addition* to the greeter rendering delay problem described in the previous comment. As noted before, the stale frame issue is overshadowed by the greeter rendering delay in most cases.

For all the following the notation is : d = dash frame arrival, g = greeter frame arrival, {...}=screen off period

Basic stale frame:
d {g1} g2 ... => d, g1 are rendered after screen is turned on (d seen as a "flash")

Greeter delay overshadowing stale frame:
d {} g1 g2 ... => d is rendered when screen is turned on, since we have no newer frame at that time

The stale frame issue is not seen for slow power button strikes with the greeter, because the greeter is animating (producing frames) and if the strikes are over 100ms apart the oldest frame (which is the stale frame) gets dropped by our frame dropping policy since we are not consuming it. This is:

d {g1 g2} => Time between strikes > 100ms: g1, g2 are rendered (d = stale dash frame is evicted)

Experiments supporting the stale frame issue:

1. If we simplify the greeter to be a filled rectangle, without any animations, we occasionally see just the dash when the screen is turned off and on again. We need to force another rendering (e.g. by touching the screen) to see the greeter. This happens because the restarted compositor only renders one frame (the stale one), since it has no knowledge that other frames exist (this is a bug in Mir):

d {g} => Only d rendered when compositor restarted, need to trigger to render g

2. In the previous case (1), if we force the compositor to render 2 frames on start instead of 1, we *always* get a dash "flash" after turning the screen on, even if the time between the button strikes is not small. Note that this is different from the normal greeter case because in this case there is no animation going on, no extra frames are sent, and therefore our frame dropping policy doesn't kick in to evict old frames.

d {g} => Both d,g rendered when compositor restarted, regardless of time screen is off

To fix the stale frame issue, Mir should drop all old frames for a surface if a new frame for that surface arrives while the screen is turned off:

d {g1} g2 ... => g1 arrived while screen was off, d is dropped, so in the end g1, g2... are rendered

Note how this fix doesn't resolve the greeter delay problem since in that case no frames arrive while the screen is off.