OSes

Bittersweet post tells devs what they already knew: The framework is too slow

Microsoft claims to have achieved a "leap forward" in performance for WinUI 3, the current native framework for Windows apps, with a 25 percent improvement for the parts of File Explorer coded using this framework.

Software engineer lead Beth Pan posted figures for the WinUI portion of File Explorer, showing 41 percent fewer memory allocations and 45 percent fewer function calls. She added that some optimizations "involve small or large breaking changes," so they will be opt-in at first for developers using the framework. The plan is for the optimizations to become the default in future versions of WinUI and the Windows App SDK, with opt-out available when needed.

The new optimizations are part of a push to make Windows more responsive. In March, Windows boss Pavan Davuluri promised to improve the quality of the operating system, including a commitment to a "faster and more dependable File Explorer." His post noted that Microsoft intends to "move more experiences to WinUI 3" for faster responsiveness.

Pan's post is bittersweet for developers. Performance issues with WinUI 3 have been well known for years. Although Microsoft calls it a native framework, that is a stretch. WinUI 3 is based on WinRT (Windows Runtime), a component interface first used in Windows 8 that sits between application code and the underlying Win32 API, which has a better claim to being native. An advantage of WinUI 3 is its support for Fluent UI, the Windows design system. Developers using WinUI 3 get the Windows 11 look and feel, but not the best performance.

"WinUI 3 is currently measurably slower than both WPF [Windows Presentation Foundation] and UWP [Universal Windows Platform]… this is NOT OK," said one comment. Another said that "you can't build a WinUI app and call it smooth at the same time."

Component vendor DevExpress has also posted about WinUI 3 performance issues. The company stated that WinUI component architecture has the potential for fast rendering and animation, but that "unfortunately, each action within a component requires WinRT interop, which is slow."

These concerns undermine Davuluri's hope that using more WinUI 3 will fix Windows 11 performance, unless the framework itself is improved, as Pan now claims.

Another longstanding gripe among Windows devs is that Microsoft's developer division has created frameworks that the Windows and Office teams have not always adopted consistently. Internal tensions go back many years. Some may still remember early builds of "Longhorn," the code name for Windows Vista, having to be reworked before Vista's eventual release in 2007 because of performance issues with .NET. This caused distrust of .NET in the Windows team. "What you need to do is actually use your framework across the company," said another comment. Pan replied, insisting "that's the push."

This is exactly what developers using WinUI 3 want to hear, but the long and tangled history of Windows UI frameworks suggests that a consistent and enduring company-wide approach is unlikely. ®