Is Windows Composition API dead?

[HppZ]

no commits since 2019, so is Windows Composition API dead?

[Gavin-Williams]

I think it is, although some people are saying no.

The problem with this system is that Microsoft don't know what it is and what to do with it. They targeted it as a system that sits between DirectX and WinUI, but then said that it's only meant to assist WinUI - the layer above.

What they should have done is built it out to be a complete visualization system that WinUI, CustomUI's, Graphics apps and games could be built upon. And I'm sure people will say 'no, I'm wrong, it's this and that' and here we are, with no updates, no discussion and no general usage. It's very unclear to me what this system is meant to be and how I'm meant to integrate it into other things that I'm doing. And did I mention that no one uses it?

I am in fact using it at the moment in an assignment (just because I don't want to use raylib), but beyond that, how am I meant to use it? UI.Composition runs out of steam pretty quickly.

• Where is the Swapchain for example?
• Where is the shader system?
• How can I render arbitrary 2d and 3d geometry?
• How do I use Immediate mode?

If I'm using WinUI, then I'll likely just use WinUI. If I want to do something else like make a custom UI for games or for graphics projects, I don't think the UI Composition system is built out enough. It's missing a lot of features. I'll just revert to SharpDX or one of the new libraries like TerraFX or Vortice or - puke - use C++ and DirectX directly.

Microsoft really struggle with modern graphics and .Net graphics. I think it's because the game development ecosystem team are only focused on C++ DirectX, while the .Net teams aren't really considering games and graphics. Until they are forced to work together and come up with some modern C# graphics libraries that are capable for use in various project types - including visualizations, simulations and games - we'll keep getting half-baked projects that are difficult to use in real projects.

And yes, some people will use UI.Composition, but it has such a narrow scope, I just see this being killed off. Happy to be proven wrong.

[pjmlp]

Apple and Google are able to provide UI.Composition like APIs for Swift, Java/Kotlin and Dart respectively on their platforms, while on Windows we are forced to reach out for community projects.

This should be considered as it plays a role in getting developer adoption.

[sylveon]

I think there is a misunderstanding of what Windows.UI.Composition is here.

It is certainly not a full graphics library, it's meant for apps to communicate with the system compositor (DWM) to tell them how to compose their GUI.

You're right that's it's sort of always used with UWP system XAML, but that's just a consequence of UWP system XAML itself being tightly integrated with the system compositor. You could technically build your own UI library on top of Windows.UI.Composition, for example the Lottie UWP library does.

Other UI libraries tend to do their own UI composition rather than rely on DWM to do it (for various reasons, the primary ones probably being that they have complete control over the composition code and multi-plat support). Even WinUI 3 does its own composition and doesn't rely on Windows.UI.Composition (to not have to rely on OS updates for composition changes), which is why things like acrylic have stopped working there because custom composition cannot read what's behind the app window.

The documentation about Windows.UI.Composition, aka the Visual Layer, is pretty clear about the goals of it:

The Visual layer provides a high performance, retained-mode API for graphics, effects and animations, and is the foundation for all UI across Windows devices. You define your UI in a declarative manner and the Visual layer relies on graphics hardware acceleration to ensure your content, effects and animations are rendered in a smooth, glitch-free manner independent of the app's UI thread.

• DWM's swapchain is abstracted away from the Visual Layer (it's part of the Graphics Layer). You alter DWM's visual graph and that graph is rendered to the screen each VBlank.
• Arbitrary shaders aren't supported and would be a security issue (DWM runs in a privileged context and handles DRM-protected content and other app content). You can combine a variety of D2D1 effects when building composition effects, but never arbitrary shaders.
• You can give it arbitrary 2D vector content using CompositionPathGeometry, or arbitrary 2D/3D content with CompositionDrawingSurface or ICompositorInterop::CreateCompositionSurfaceForSwapChain.
• It's retained mode, so immediate mode is not and will most likely never be supported.

You could probably do a game UI by putting the 3D content as the bottom layer with a CompositionDrawingSurface or the result of CreateCompositionSurfaceForSwapChain, then put all game UI on layers above. But that seems needlessly complicated, and Windows.UI.Composition was obviously meant for user interfaces, not games, so I'm not sure what performance would look like.

I don't expect it to be great, since using Windows.UI.Composition means you're relying on DWM to draw your UI, so exclusive fullscreen is impossible (because that bypasses DWM) and DWM drawing anything on top of a DXGI swapchain means that DirectFlip (an optimization for borderless games which skips DWM's swap chain entirely and directly sends your own swapchain to the monitor) cannot kick in. Which means that for example, VSync is forced on you (since DWM only renders each VBlank), your swapchain is always copied to DWM needlessly unless you used a swapchain made via CreateSwapChainForComposition, etc.

Sorry to disappoint, but if you're looking for a modern (for a subjective meaning of the term) way to do graphics, an UI composition library is probably not what you're looking for.

[GeorgeS2019]

What happen to previous Windows Composition API initiative?

Another WinUI 3D request discussion

Microsoft 3D Composition API show case