Development Blog · CircumSpector/DS4Windows · Discussion #21 (original) (raw)

2021-12-22

What's happened so far

I've started this blog way after the rework has started so this post will be used to recall and describe roughly what has happened under the hood so far.

Switched from using XML to JSON

Everything that needs to be persisted (application configuration, controller properties, and last but not least the profiles) will be using JSON instead of XML. Reason being that the entire project doesn't really use anything that warrants use of a very verbose and complex markup language like XML, it's easier to read for the human eye (and to edit) and battle tested serializers in .NET exist for it in ages.

This does not mean that every customization previous DS4Windows users made (profiles, macros, etc.) is lost, there are XML to JSON converters in development, that will take care to transparently migrate >90% of the existing configuration, where possible.

A ton of hours was dumped into dissecting and replacing the existing XML (de-)serializer which was hand-crafted! It was a monster; tons of duplicated and temporary variables, string and indexes used everywhere to keep track of states and objects... Nobody will miss this beast 😁 The way data gets persisted also has been completely redesigned and follows a true object-oriented pattern now. A "profile" is now a POCO with an object graph that is (de-)serializable with ease and is very simple to extend with features in the future.

UI rework

Adonis UI was introduced to unify the look and feel and also make the styling easier. This may or may not be the permanent solution as there are many other frameworks out there that offer more features but for now it's enough to give the UI a fresh look and also a more coherent dark theme.

The changes may be subtle but it makes working with XAML and WPF in general more fun 😀

Rewriting Profile Editor

This is a huge but important task. The entire profiling system is based upon design sin after design sin which makes it incredibly hard to understand, or even extend. Instead of having an object-oriented approach to store, retrieve and organise profile data countless arrays, indexes, fields and copies of fields, references here and there were used. This mess needs to be untangled and redesigned.

This is currently ongoing full throttle.

Addressing and fixing many memory leaks

Disclaimer: technically it's not really leaking memory since in a managed language like C# it's quite hard (albeit not impossible) to actually allocate memory that is never freed again during application runtime, but for the sake of simplicity lets stick to the common term when a lot of heap memory is allocated that puts a lot of pressure on the garbage collector and leaves big lumps of unused memory dangling around for many seconds, if not minutes.

With that out of the way the input handling logic (reading packets from the actual hardware and transforming it to be fed to the virtual output devices) has been optimised in a major way. Previously heap memory usage was running away slowly but steadily during program usage due to many unnecessary allocations and improper use of the HID-Library abstraction layer. With these fixes in place, memory usage during runtime with one or more controllers connected was greatly improved and stabilized.

A lot of design sins also hide in the Profile Editor implementation, the classes involved are currently ported over to utilize IoC (dependency injection) so singletons will remain in memory once and just the relevant references will be updated during runtime instead of allocating and destroying a ton of objects when invoking the Profile Editor and related types.