3 ms·

> Unmatched Native Performance Can anyone offer any insight on this? If memory serves, WPF is backed by DirectX. How can they hope to beat that performance? Pe

> Unmatched Native Performance Can anyone offer any insight on this? If memory serves, WPF is backed by DirectX. How can they hope to beat that performance? Performance improvements over its MVVM? Modern UI toolkits tend to add high-level abstractions and degrade performance (e.g. by relying on web technologies), rather than enhance it.

sleepinseattle 7y ago
The framework layer of WPF is implemented in C#. WinUI is all C++, including the framework and the compositor that makes the DirectX calls. In the framework layer, typical UI updates are faster because the WinUI data binding system uses code-generation rather than the reflection-like runtime binding system that WPF has. WinUI also includes the rather incredible Windows.UI.Composition API’s, with things like ExpressionAnimation that enable lots of cool animations (like parallax, sticky header, or cursor-relative) at a stable 60 FPS. Disclosure: I work at Microsoft on the Windows team.
- MaxBarraclough 7y ago
  Great answer, thanks. > code-generation rather than the reflection-like runtime binding system that WPF has That's a good move. If a convenient abstraction can be implemented in a way that 'compiles out', it ideally should be implemented that way. Does this enable more compile-time checks?
  - sleepinseattle 7y ago
    Yes, in WinUI you get build breaks if you have a typo in your property name :) It also adds the ability to bind to functions, which can eliminate a lot of ViewModel boilerplate for computed properties.
toast0 7y ago
>> Unmatched Native Performance > Can anyone offer any insight on this? Unmatched doesn't mean good or bad, it just means it's not the same, and implies it's good. If it were a real claim, they would have some numbers and an example of old vs new or new vs web or compare it to Android UI or something else known to be bad. And then we could pick apart the code examples and have a good time.

sleepinseattle 7y ago

The framework layer of WPF is implemented in C#. WinUI is all C++, including the framework and the compositor that makes the DirectX calls. In the framework layer, typical UI updates are faster because the WinUI data binding system uses code-generation rather than the reflection-like runtime binding system that WPF has. WinUI also includes the rather incredible Windows.UI.Composition API’s, with things like ExpressionAnimation that enable lots of cool animations (like parallax, sticky header, or cursor-relative) at a stable 60 FPS. Disclosure: I work at Microsoft on the Windows team.

MaxBarraclough 7y ago
Great answer, thanks. > code-generation rather than the reflection-like runtime binding system that WPF has That's a good move. If a convenient abstraction can be implemented in a way that 'compiles out', it ideally should be implemented that way. Does this enable more compile-time checks?
- sleepinseattle 7y ago
  Yes, in WinUI you get build breaks if you have a typo in your property name :) It also adds the ability to bind to functions, which can eliminate a lot of ViewModel boilerplate for computed properties.

toast0 7y ago

>> Unmatched Native Performance > Can anyone offer any insight on this? Unmatched doesn't mean good or bad, it just means it's not the same, and implies it's good. If it were a real claim, they would have some numbers and an example of old vs new or new vs web or compare it to Android UI or something else known to be bad. And then we could pick apart the code examples and have a good time.