Wednesday, December 12, 2018

WPF and High Performance Graphics

Here's the problem with WPF/XAML for high performance graphics. You have to depend entirely on Microsoft's website for documentation. The problem with that is the documentation is fragmented, disconnected and often, seemingly, written by many individuals, just like I'm sure there are many, many developers working on the C# language, WPF APIs, Visual Studio, .NET Framework, DirectX graphics engine and XAML - 6 giant areas of technology (SQL Server and Azure get honorable mention here). Previously, we, the application developer, always relied on books to bring it all together and help the poor developer with a roadmap to successfully accomplish the job. The books doing this have dried up! Nobody likes to take the significant hit to write a 1500 page book while the underlying technology rockets forward in light-speed.

Thank God for Jack Xu and Andrew Troelsen. But it seems like they're running out steam - HA! Aren't we all! (Jack, I love you, but you need to hire an editor and you need a small, skilled team to work on and review your source code examples. Also, reorganize your books into volumes and release new editions as the underlying technology moves on and to fix the mistakes. I'd for one would love to help! Feel free to contact me)

Here's a subject nobody delves deeply into that paints a roadmap. Using WPF, XAML, C# to write high performance graphic intensive application that renders using the "Visual Layer." If anybody can help with the topic, please contact me.

Friday, October 12, 2018

MVVM Hurts My Fingers

I've refactored my WPF desktop app to be fully MVVM according Microsoft's definition of the design pattern. That includes binding the Views to their own Viewmodels, implementing data binding, commands and type converters for data binding. Speaking of type converters for data binding, it dawned on me that I was confusing that concept with XAML type converters. Nope, two completely separate mechanisms that provide for different functions. Anyway, the app is now nicely componentized and DRY but, because of the requirements of Microsoft version of MVVM and XAML, the codebase exploded in lines of source.

I was introduced to the Caliburn.Micro framework by one of Jack Xu's books. Caliburn.Micro implements a simplified MVVM binding process that reduces source code line count as compared to straight XAML binding. The problem is that I don't want to take the hit to convert to it at this point. Perhaps that's a bad idea.

I do very much appreciate using C# 7.2 as the language for the app. The language itself and its modern features, as well as the features of Visual Studio 2017, save quite a bit of typing. I am currently (12/2018) using .NET Framework 4.7.2. It's always hard to figure out where the language ends and the framework begins.

The async/await construct does indeed make multi-threaded code readable. The problem with async/await mechanism is that you really have to understand it well, it's not as simple as it looks (as it was intended to be). That is, going async in the async/await world does mean you're going multi-threaded. It can simply mean the UI thread moves on and the code that follows (under) the awaited call will resume after the awaited call returns, without switching threads - pure black magic. I do like the readability of the mechanism. Believe me, readability, as the app grows in size, is EVERYTHING.

Friday, August 31, 2018

Going XAML/WPF Requires new threading model, and Legacy WinForms Charting

The conversion from WinForms/VB.NET to WPF/C#.NET is tougher than anticipated. WPF is designed, by way of XAML, to have a data pull, autonomous, UI system. Base on a design pattern called Model-View-ViewModel (MVVM). The pattern should have been called View->Viewmodel->Model (V>VM>M) since the View is only supposed to know about (references) the Viewmodel and the Viewmodel is only supposed know about (references) the Model. I also found out that WinForms Chart class was not ported to or supported by WPF. Therefore, I'm mostly tossing the View/ViewModel binding concerns and concentrating on core functionality of the app.  That is, charting real-time data and while keeping the UI interactive. So that means wrapping the WinForms Charting namespace to work in WPF and converting WinForms BackgroundWorker threads to work in a WPF environment. The application is forced by XAML to be partitioned at a high level into Windows, User Controls and Pages, each locked to their own partial class and inheritance chain. This architecture requires a lot of inter-class access facilitation. Not to mention the added complexity of trying to adhere to the MVVM pattern of the View only knowing of the ViewModel and the ViewModel only knowing of the Model. It's a challenge.

Of course, working with C#.NET is easier than VB.NET.