Comment 5 for bug 1340510

Inverstigation indicates that the main cause of the issue is a delay in unity8 when showing the greeter. There may be a stale frame problem in Mir hiding in here, but I can neither confirm nor disprove this at the moment (so setting this bug as incomplete for Mir), since the effect of unity8's rendering delay is overwhelming.

What I see happening is:

1. User strikes power key
2. USC catches event, blanks screen, notifies unity dbus service of change in display state
3. unity8 gets display state change event, tells greeter to show
4. user strikes power key again
5. USC catches event, unblanks screen, notifies unity dbus service of change in display state
6. If (4) happens very soon after (1) (and note that 3,4 can occur concurrently), unity8 has not yet had the time to show the greeter on screen, so the user sees a "flash" of the dash first, and soon after the greeter is displayed.

Experiments supporting the unity8 delay hypothesis:

1. The closer the two power key strikes are, the longer the "flash" of the dash is.
2. In USC, moving the unity dbus service display change notification sooner (e.g. before blanking the screen), makes the dash "flash" shorter (since we give unity8 more time to render).
3. Simplifying the Greeter (e.g. hacking its qml to display a red rectangle instead of all the user info and background), reduces the dash "flash" time, since it reduces the time unity8 needs to render the greeter

Note that unless unity8 can get the display state change event and render the greeter in less than the time USC needs to react to the two power key strikes (to blank and unblank the screen, respectively), we are always going to have this issue (it's an inherent "race").