Terminal: WT should start up fast: profile the startup path and trim anything that takes a while

[phgmacedo]

Steps to reproduce

1. Click to launch Windows Terminal

Expected behavior

Windows Terminal should be ready instantaneously like windows console, or like Sublime Text.
Windows Terminal can't be slower than windows console.

While Windows Terminal is fast compared with other tools like Visual Studio, or iTunes, it is still not fast enough for a Terminal application.

Actual behavior

It takes too long to startup. It is not ready instantaneously. It's not as fast as windows console.

[zadjii-msft]

I mean, the Terminal is doing a lot more than the console ever was. I'm not sure there's much more we can do to optimize our UI setup. Conhost was using basically the simplest Win32/GDI interface possible, and the Terminal needs to stand up a XAML stack. Even if we somehow had a server process that already had the settings pre-loaded, we'd still need to stand up the UI stack.

At least the Terminal is faster at processing output than the console ever was, and opening new tabs/panes is certainly faster than opening a new conhost is.

Maybe there's something we can do here to optimize the creation of the XAML stack.

[phgmacedo]

and the Terminal needs to stand up a XAML stack

XAML stack means UWP?

[mdtauk]

and the Terminal needs to stand up a XAML stack

XAML stack means UWP?

This uses a Xaml Island for now, but with WinUI 3.0 Xaml will not be tied to UWP, and can be used with Win32 code

[zadjii-msft]

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application.

The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

[AnuthaDev]

@zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet.

[zadjii-msft]

I mean, that's a _possibility_, sure, but I think as the Terminal UI gets more elaborate, using DComp for the entire UI is going to be less and less feasible. Plus, if we do want 3rd party developers writing extensions to provide their own UI elements for the Terminal (see #4000), it'd probably be more developer-friendly to ask them to write XAML components rather than DComp visuals

[phgmacedo]

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application.

The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

It looks and feels like a UWP app though. Maybe that's the problem.

[mdtauk]

@zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet.

Part of the idea for this project is to modernise the terminal UI and feature set, supporting multiple console types, and show the best of Windows.

Choosing not to implement the modern UI stack, is not within that scope. Windows 10X's shell has moved to XAML, and XAML is being decoupled from the OS and being open sourced, so the community can push it forward, without relying on new OS updates.

By the end of the year, all the code should be in the GitHub, and then the community can explore how to improve performance.

The app is using C++ and so is XAML. Being able to move out of the use of an Island will possibly bring with it some perf benefits by default

[mdtauk]

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application.
The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

It looks and feels like a UWP app though. Maybe that's the problem.

It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere.

[phgmacedo]

It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere.

Well, I can't really do anything about that other than to give feedback as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform.

[AnuthaDev]

I mean, that's a _possibility_

So you're telling me there's a _chance_ 🤣😅

I hope winUI 3.0 alleviates this situation.

[DHowett-MSFT]

@AnuthaDev it’s nowhere near ready for primetime use (by developers who we can’t go bother when stuff goes wrong), but this repository does produce a WPF control that’s really just a standard Win32 HWND with the terminal surface on it. It’s pretty much the DirectWrite renderer wired up to a surface.

Our long term plan sees us producing composable controls other developers can integrate into their own experiences.

If only we had all the time in the world :smile:

[AnuthaDev]

If only we had all the time in the world :smile:

@DHowett-MSFT Okay, serious question. Suppose somebody else does the entire work, what would your preference be XAML or win32 HWNDS (Provided that win32 significantly reduces memory consumpition and startup time)?

[mdtauk]

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

[oising]

Well, I can't really do anything about that other than to give feedback as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform.

@phgmacedo Why would you avoid future Windows updates? WinUI 3.0 brings many benefits, and as a dev, you're never going to be forced to update WinUI either. Opting out of Windows updates seems to be counter-productive in general - or are you just making an orthogonal, abstruse gesture about your displeasure? It may be more effective to visit the new WinUI 3.0 site and assuage your worries.

[AnuthaDev]

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND

[mdtauk]

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND

Yea, that is a very classic windows concept. Every control is also a Window.

@oising I think he is maybe expressing a preference for the Win32 visual look, compared to the Windows 10/WinUI look. Could be the density of controls, or just an old school familiarity with WinForms / WPF.

[DHowett-MSFT]

density

So, WinUI 2 started to offer a "Compact" sizing dictionary that changes control sizes to more closely match classic Win32. That might be worth investigating.

[DHowett-MSFT]

After testing: on account of we don't have too much UI right now it doesn't really help us.

[mdtauk]

Density keeps to the 32px min height for touch controls like buttons and text boxes I believe. The flyouts from the Add Tab button could be affected, but until WinUI 3, flyouts are not affected by setting a compact density.

[DHowett-MSFT]

Now, I'm going to mark and minimize all the complaining about our choice in UI framework as off-topic and turn this into the issue for "make sure terminal launches fast". Kay? Kay.