I agree - the workflow setup is quite complicated. There is no "WPF-to-NoesisGUI" converter. But NoesisGUI was initially designed as UI middleware for the game engines so it's understandable.
You can find your own perfect workflow. For example, in our new game we use exactly the same WPF project (including C# code) with NoesisGUI - the game itself has Roslyn compiler and preprocess WPF C# code to make it 100% compatible with NoesisGUI (it also wires actual game API instead of "fake" API). XAML files don't need any preprocessing and used as-is. Our game engine also allow hot-swapping of C# and XAML code and any assets - this dramatically simplifies the development workflow and modding.
In my opinion, MonoGame integration
https://github.com/aienabled/NoesisGUI.MonoGameWrapper is much easier to understand and setup the workflow (if you don't need right now the crossplatform support and don't need all the Unity engine features - especially if you prefer the code-first approach instead of bothering with clumsy Unity Editor). Thought there is no separate WPF project in this repository it's quite easy to setup one. If you're looking for the already setup WPF project, I've done something close to this in Ammy integration sample
https://github.com/aienabled/NoesisGUI.AmmyIntegration (based on SharpDX, but I've not updated it for a few months so it will require some API fixes to properly work with latest versions of NoesisGUI and Ammy) - it contains a separate WPF project from which the Ammy files are automatically used by the application - SharpDX app automatically convert Ammy to XAML; the app is listening to the file system changes to reload Ammy files. But SharpDX app is using separate C# classes for each Ammy/XAML file, it doesn't reuse the same C# code files from WPF project.
The reason why you can't simply take a WPF project and run it in "Noesis engine" is that NoesisGUI uses different namespaces (everything is in Noesis, not in System.Windows.Controls, System.Windows.Media, etc) and in some cases it has a little bit different API - the most bothering one is that NoesisGUI C# SDK uses in its API float instead of double, so sometimes you simply cannot compile WPF code for NoesisGUI API because of this and few other issues. We're using a fork of their C# SDK (and merging it with the latest versions) to workaround all the WPF difference issues (there are really not much, less than 1000 LOC) until they provide a proper fix. But good news is that almost everything different from WPF is already reported to their bugtracker and they're working on it.
Also NoesisGUI doesn't have a concept of WPF Application and doesn't understand App.xaml file. But it's easy to use the same XAML files and it's possible (with some Roslyn preprocessing and C# SDK fork) to reuse C# code. If you're curious about the Roslyn preprocessing code see this gist
https://gist.github.com/aienabled/d20c5 ... be8b76bd09
Ideally, I would like to have NoesisGUI C# SDK to have
exactly the same namespaces as WPF and exactly the same API - so we will not need to use Roslyn for preprocessing of C# code and no need to fork C# SDK API. I'm completely sure it's possible (the changes are related to how they generate SWIG wrappers over C++) so perhaps some day we will receive a separate NoesisGUI C# SDK package which is done this way or the same C# SDK package but with different CONDITIONAL_COMPILATION_SYMBOL (propose one - WPF_API_COMPATIBILITY). I would like to hear the NoesisGUI team comment on this.
Regarding the text rendering quality - in NoesisGUI 2.0 they've redone it and dropped colored subpixel rendering for many reasons (but implemented perfect grayscale subpixel rendering when I've complained about it - they're really listening to the user feedback!). Microsoft UWP also dropped colored subpixel rendering (one of the reasons - it's not useful when you rotate your device to landscape mode as the RGB rows layout change to RRR, GGG, BBB rows) and use grayscale subpixel rendering - but NoesisGUI 2.0 render text with much better quality than UWP, in my opinion. And with colored subpixel rendering at 1.2 it was just a little bit better on very small fonts.
Regarding the performance - NoesisGUI was designed to be fast and reliable, to provide great user experience even on low-powered mobile devices. It's much faster than WPF/UWP in terms of controls loading speed and rendering speed (and memory utilization is also comparable to WPF/UWP). Previously (with our Unity-based game) we've used a workflow where we had a separate WPF application project and reused XAML files (but no C#) from it in the Unity-based game. There are more than hundred of user controls and thousands of XAML resources (such as styles, templates and brushes). WPF project has a complete "demo" logic so we could test whole UI separately from the game (it was easy to prototype the UI and ensure everything works as expected in WPF). And close to the game release, this WPF project literally crawled - more than 5 seconds to launch, framerate dropping dramatically sometimes (and usually not stable 60 FPS). There is only UI and very light logic. While in the game the controls loaded just in a second and the game maintained 500 FPS easily on mid-tier GPU while rendering exactly the same UI as WPF (but with the 3D game behind the UI! So if we disable the game rendering it will be much more). I didn't measured exact numbers but NoesisGUI is obviously faster. I need to mention that this game still uses NoesisGUI 1.2. In 2.0 they've improved performance even more and get rid of XAML precompiler (so NoesisGUI load XAML files directly - and do this much quicker so no preprocessing is required).
Regards!
