Comment 10 for bug 1672401

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I was thinking about this bug last night. It occurred to me the black screen is probably Mir's mesa-kms driver's first frame that it flips on start-up. As far as Mir is concerned this is a very low-severity issue since the shell should then render a proper frame 16ms later. However since Unity8 is taking several seconds to render a "proper" frame perhaps we need to change the start-up order...

Presently:
1. User enters password successfully
2. unity-system-compositor starts and Mir's mesa-kms driver flips a black frame.
3. unity8 starts and Mir's mesa-kms driver flips another black frame that USC probably displays.
4. (several seconds later) unity8 has a proper frame ready and displays that.

If we got rid of the dummy black frame from Mir (and we need to anyway since that is us hardcoding a dependency on the GL renderer in the driver) then the best case outcome from that might be several seconds of a frozen login screen before Unity8 appears. I'm not sure that's really any better than blackness.

It might be better for Unity8 to take responsibility for this and flip some splash screen immediately on startup for the user to see that everything is OK while it compiles QML and whatever.

Also nice would be for USC to display a spinner while Unity8 is not ready (hasn't displayed any frames). However we can't do that right now while Mir is inserting a black frame of its own, which would make USC think Unity8 is immediately ready.