Decouple Splash Screen from UWP App Activation

[lukeblevins]

Currently, only UWP apps are capable of displaying a splash screen during their activation. Since splash screens are a valuable way to provide instant feedback to a user upon invoking an app (also in other non-Windows platforms), the team should invest in the following solution:

Decoupling this experience from the UWP app model

Currently the only way to perform actions like extending the splash screen is to access it during the activation process, and "imitate the splash screen that Windows displays for your app." I'm proposing we provide a WindowSplashScreen object as part of the lifetime management of the WinUI 3 Window abstraction. For scenarios where using CoreWindow is not desired, the WinUI team should work with the Project Reunion team to develop a DesktopWindow which is a direct abstraction of a Win32 hWnd to include the new WindowSplashScreen and UWP titlebar style by default.

Essentially, the WinUI 3 Window object should abstract away the details of both CoreWindow and DesktopWindow. Furthermore, the WindowSplashScreen should have a built-in way to control the extended visibility of the SplashScreen without developers needing to imitate the main one.

What does everyone think of this proposal? Is it feasible?

[lukeblevins]

I know @marb2000 will have valuable input for the discussion. 😉

[marb2000]

Thanks @duke7553 for opening this proposal. Supporting a splash screen in WinUI is on our radar, although no planned for this 2020 year.

It's soon to think about the implementation details, although I can anticipate that we desire to avoid diverging the Window class. Having DesktopWindow in WinUI sounds like that. Perhaps we change in the future, but we should try not to do it.

Main Requirements

There are several requirements that I have in mind:

1. The splash screen APIs should work for UWP and Desktop.
2. The splash screen should work with packaged and unpackaged applications.
3. Deliver a simple default developer experience that allows developers to set properties like an image and background color. The splash screen is displayed immediately when the user launches the app. As soon as your app is ready for interaction, the splash screen is dismissed.
4. The splash screen is borderless without title bar and shows normal (SW_SHOWNORMAL) on the center of the screen.
5. Allow changing the content of the Splash Screen (e.g., Progress Ring or Progress Bar) and allow updating the content (e.g., updating the progress bar, or text blocks describing what is happening)

Some thoughts

• As a consequence of req.2 the splash screen should be defined out of the package.appxmanifest.
• UWP and WPF made made to set a basic splash screen super easy.

References:

• Create a customized splash screen in UWP
• Custom splash screen sample for UWP
• Creating a custom splash screen in WPF

[jaigak]

Although you can create a splash screen in WPF, the UWP splash screen works differently. In WPF the splash screen is rendered by your app's process while the UWP splash screen is rendered by the Windows Shell not by your app. This is why you see a splash screen immediately after you launch it. Here's how it works:

• User launches the app from the Start Menu.
• A window is created by the shell and the splash screen image is rendered.
• The app is started as a background process and the handle for the windows is given.
• The app sets the content and activates the window. (Any content including DirectX, HTML or XAML. In XAML apps you use Window::Current().Activate() which will internally activate the CoreWindow.)
• The shell renders the content set by the window.

Since the splash screen is rendered by the shell and not by the XAML platform it's not really possible to decouple it from UWP without modifying the Windows Shell. Also, WinUI is supposed to be open source and they can't just open-source Windows. They could get rid of the default splash screen rendered by the shell and reimplement the splash screen in pure WinUI. However, there are some disadvantages to this approach:

• DirectX UWP games and apps don't use XAML need to reimplement the splash screen since they can't rely on WinUI for a splash screen.
• UWP Apps will no longer be responsive at launch since the entire process needs to loaded into memory before the splash screen can be displayed. This will turn UWP apps into apps that show a busy loading cursor which I don't like since you don't really which apps you've started without seeing the Task Manager.

[roboraSimon]

You say that like it's some great benefit, whereas what it actually means is that apps that should load instantly (like calc.exe) instead show a splash screen which doesn't correctly capture user input.

So the entire process is slowed down just so we can slap a pointless splash screen on an app that doesn't need one.

[mdtauk]

A future Splash Screen implementation could take on board the Extended Splash Screen ideals, and become something more customisable.

[LeftTwixWand]

I suspect, activation services will be changed, and maybe even it will be possible to switch off initialization of services and disable splash screen.

[lukeblevins]

My proposal was to provide an easy, standardized way to add and extend a splash screen only if needed. Because hWnds obviously won't have them by default. 🙂