[!NOTE] This article relates to the legacy WinRT native APIs. For new native app projects, we recommend using the OpenXR API.
This topic explains the impact of switching between 2D XAML views and immersive views in your DirectX app, and how to make efficient use of both a XAML view and immersive view.
On HoloLens, an immersive app that may later display a 2D XAML view needs to initialize that XAML view first and immediately switch to an immersive view from there. XAML will load before your app can do anything, which adds a small increase to your startup time. XAML will continue to occupy memory space in your app process while it stays in the background. The amount of startup delay and memory usage depends on what your app does with XAML before switching to the native view. If you do nothing in your XAML startup code at first except start your immersive view, the impact should be minor. Also, because your holographic rendering is done directly to the immersive view, you’ll avoid any XAML-related restrictions on that rendering.
The memory usage counts for both CPU and GPU. Direct3D 11 can swap virtual graphics memory, but it might not be able to swap out some or all of the XAML GPU resources, and there might be a noticeable performance hit. Either way, not loading any XAML features you don’t need will leave more room for your app and provide a better experience.
The workflow for an app that goes directly from XAML to immersive mode is like so:
If your app needs to implement some amount of rendering in DirectX for the XAML view in Windows Mixed Reality, your best bet is to create one renderer that can work with both views. The renderer should be one instance that can be accessed from both views, and it should switch between 2D and holographic rendering. This way GPU assets only load once, which reduces load times, memory impact, and the amount of swapped resources when switching views.