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, a generally immersive app that may later display a 2D XAML view must initialize that XAML view first and immediately switch to an immersive view from there. This means XAML will load before your app can do anything. As a result, there will be a small increase in your startup time, and XAML will continue to occupy memory space in your app process while it resides 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 start up 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 will avoid any XAML-related restrictions on that rendering.
Note that the memory usage counts for both CPU and GPU. Direct3D 11 is able to 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 be able to switch between 2D and holographic rendering. That way GPU assets are only loaded once - this reduces load times, memory impact, and the amount of resources to be swapped when switching views.