Unity8 creates a blank black window for windowless apps

Come to think of it, solving bug 1543467 might solve this.

Can you please check this is still the case? We've landed multi-window support now.

In xenial it's still a problem.

I also just tried the PPA where dandrader says new fixes exist, but can't test it due to many crashes: bug 1578461

Even with the preliminary multi-window support, this bug persists...

Confirmed today on unity8 8.12+16.04.20160504.2-0ubuntu1 from
ppa:ci-train-ppa-service/stable-phone-overlay

Test case: Xmir :0 -rootless --desktop_file_hint=unity8 -sw
Expected: No window to appear
Observed: A black window appears

I'm not sure if/how we solve this, unity8 wants to show the splash screen as soon as it knows an app is being launched, so that there's an immediate UI feedback to the user. When we get the first frame from the client, we hide the splash screen. It works fine for native apps.

Not sure what Xmir does, but since we're not treating it any differently I'd venture to say it's Xmir's fault for drawing the black before there is an app in there.

Unity8 needs this bug fixing for one simple reason:
Even apps that do display a window "immediately" will get a splash screen of the wrong size displayed before a window of the correct size appears. This will be particularly important after bug 1606501 gets fully fixed.

And no, it's not invalid for Xmir to not create a window on start-up in rootless mode, it is correct behaviour. It's a server and has no windows until the X client creates one. It's distracting and confusing for Unity8 to create a black window where there should be no window at all.

Bug 1606501 is fixed now, btw.

How do you propose we fix this? Waiting for the client to create a window won't be something we want to do.

Again, I don't believe we're drawing the black. We're displaying a splash screen immediately and only hide it when the client has drawn a frame. So "it's not invalid for Xmir to not create a window" is correct, but if that was the case we'd see the splash screen, not black.

As for initial surface geometry, it's only a problem the first time ever you launch an app, as we're remembering its previous geometry and open the splash screen at the size we'll tell the app to be when it's launching now. I.e. we don't rely on the app remembering its geometry, we do this ourselves.

Actually the bug that bug 1606501 is a duplicate of is fixed. I haven't yet confirmed that 1606501 is really fixed too.

OK, I understand this bug is something you don't want fixed. And the description of this bug alone makes it a low priority issue, sure.

However the implications of not fixing this bug are larger. That is every time an app starts the user may see a flicker from black to the real window contents. But I expect in due time someone will log a bug for that specific consequence and it can be discussed elsewhere.

Reopened. It's not just rootless Xmir that's broken, but also basic windowless utilities:

  mirout -- --desktop_file_hint=unity8
  mirin -- --desktop_file_hint=unity8

They should not be flashing up black windows when they run, because they don't create any surfaces.

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

This is an issue for me too. The use case is media-hub on desktop. We render into a framebuffer object and pass the textures to other process (mediaplayer-app usually) that renders them in a window. We obviously do not want a window shown by media-hub-server, but we need to connect to mir to access the GPU and render into the fbo.

I'm going to say Won't Fix again. On the default socket we only expect apps - apps that will have surfaces. For those apps unity8 is showing a splash screen.

Any clients that are not apps can connect on a trusted socket - and we may decide to open a "utilities" socket, but we wouldn't accept any surfaces there.

Just to clarify:

Unity8 shows a contextual (app name, icon) and configurable (via .desktop file atm) splash screen for apps that connect on the default socket. That splash screen is replaced with the actual surface as soon as the client *draws* to it.

If, at any point, the contents are black, that means the client has drawn a black frame.

We may modify how the splash screen behaves, delay it for a very short time and have a minimum time it has to be on screen, so that there's never a "flicker".

This way a client that draws or quits (utilities?) very quickly (within the initial delay) will go straight to the surface. Any, however, that missed that mark, will appear slower than they are in reality, to avoid the splash-to-app flicker.

I've filed bug #1670442 for that.

I don't think a utilities socket is a useful solution.

Mir apps need to discover their socket automatically. libmirclient does not know or care about the difference between an app and a utility. There is only one default Mir socket it can find automatically, and only one Mir socket for Unity8.

Secondly, the utility idea only solves it for utilities like mirout and media-hub. We also have the same problem with actual apps where 'Xmir -rootless' is running for some time before the app exists. It should not be given a window until the X app creates one. Fixing this bug may also be a prerequisite for bug 1668429 if we need 'Xmir -rootless' running in advance.

I understand the original motivation for the splash screen, but we need to move out of it. Apps should launch faster so it's a non-issue. Or at least desktop mode should not show splash screens since slow launching is really more of a mobile problem.

Rootless Xmir fits just fine with a splash screen, provided it does not draw anything before its clients draw.
I disagree that "we need to move out of it" - sure, some apps launch faster, others will still take a while to launch. While the original motivation was mobile, convergence is still our target and an immediate response to launching applications is needed still.

How do you plan on solving bug 1668429 then? Start a new Xmir server for every legacy app just in time?

Remember legacy apps are not Libertine apps. The X server needs to be in place for them automatically (which is not part of their packaging).

It doesn't need to be "in place", as long as we launch it for them (ubuntu-app-launch will take care of that). And yes, the current plan is to launch a separate Xmir server per app.

There's one more thing, we need a separate Mir session per application to be able to identify the client. If we had only one shared Xmir, all of the clients connecting to that would appear as a single client in unity8.

Alternatively, Xmir could create a separate session per X connection.

See also (?) bug 1676000