Screen is black for too long during login to Unity8

[Pete Woods]

This makes me worry there's something gone wrong on every login.

It's only this slow on a cold boot. It's somewhat faster on a second login.

It'd be nice for there to be something like:

* Splash screen
* Progress bar
* User's wallpaper (blurred?)

during this time.

Maybe it's faster on bare metal, but I'm waiting a while in a Qemu VM.

== Note ==

The experience might differ depending on whether you use unity-greeter (X11-based, default in 17.04) or unity8-greeter (not installed by default yet), which is better suited for this.

[Daniel van Vugt (vanvugt)]

"several seconds" isn't 25 seconds is it? A fix for that long login delay landed in the past few days.

[Daniel van Vugt (vanvugt)]

Please attach your ~/.cache/upstart/unity8.log from immediately after login completes.

[Pete Woods (pete-woods)]

Just to be clear. I don't expect the login to be instantaneous - it never will be on a slow machine. It just looks bad for the screen to be black for the whole process.

[Michał Sawicz (saviq)]

I'm calling this a dupe of the DBus timeout, just tried here and when you log in, the greeter stays on screen for maybe 4s, then unity8 is shown within a second.

Note I'm using unity8-greeter (which you should, too, for testing the "real" login experience for unity8) :)

[Pete Woods (pete-woods)]

I'm not convinced this is a duplicate of that other bug. It takes about 13 seconds for the login here. Which is not the 25 second DBus timeout you mention.

[Daniel van Vugt (vanvugt)]

OK, I see a couple of seconds of blackness on a Xeon desktop still (even after the dbus fix landed) so it's easy to extrapolate that a VM will have even more noticeable blackness.

This is possibly related to Unity8 setting up/compiling QML things.

Although it would be nice to have transitions in USC (and that's the whole point of it existing and the nested architecture), that's probably just a "nice to have" on the USC side. I would like to be responsible for that too, as native GL animation is something close to my heart and what I've been working toward in the Mir architecture for years.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alejandro J. Cura (alecu)]

@saviq: I'm not convinced the unity8-greeter should be the "real" login experience for unity8 on classic.

When we start shipping u8 as the default we would still want to keep u7 installed as a fallback, but we can't if we install u8-greeter.

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

As a prerequisite to removing Mir's initial black frame, we would want to modify mir-demos to ensure they (the demo servers) actively paint something on start-up. Otherwise you get the situation where you're looking at an old frame (VT?) indefinitely until a client is started.

[Michał Sawicz (saviq)]

Syncing task from Mir.