In den letzten zwei Monaten habe ich mich intensiver mit Speicher-Management in .Net beschäftigt. Auslöser dafür war das Buch Pro .Net Memory Management von Konrad Kokosa [1]. Anhand der Erkenntnisse daraus habe ich verschiedene Stellen von Seeing# dahingehend angepasst, dass während der zyklischen Rendering- und Update-Logik insgesamt sorgsamer mit der Erzeugung von Objekten umgegangen wird. Grundsätzlich habe ich das Thema zwar schon immer beachtet, allerdings etwas unterschätzt – vor meinen Änderungen wurden im Kern von Seeing# pro Schleifendurchlauf locker 50-100 Objekte erzeugt, was bei ca. 60 Frames pro Sekunde 3.000 bis 6.000 Objekte bedeutet, um die sich der Garbage Collector kümmern muss. Und das auch ohne, dass der User irgendetwas macht (z. B. 3D-Kamera bewegen o. Ä.). Hier im Artikel stelle ich einige Anpassungen vor, die ich in den letzten Monaten gemacht habe.
Roland
Worklog SeeingSharp 2: Rolle rückwärts
Eineinhalb Jahre ist es nun her, als ich mit Seeing# 2 begonnen habe. Mit einigen Pausen-Zeiten dazwischen hat sich in der Zwischenzeit einiges verändert. Damals habe ich mir zum Ziel gesetzt, die Abhängigkeit auf SharpDX nicht mehr zu verschleiern und damit dem Nutzer von Seeing# mehr Flexibilität zu geben. Heute ist es aber leider so, dass SharpDX nicht mehr weiterentwickelt wird [1] und somit früher oder später durch eine andere Alternative ersetzt werden muss. Aus diesem Grund habe ich mich hier für einen Mittelweg entschieden.
Worklog SeeingSharp 2: Nugetpakete erstellen und veröffentlichen
Bei Seeing# ist es langsam so weit, dass ich die ersten Nuget-Pakete hochladen möchte. Früher im alten Seeing#-Projekt habe ich dazu noch eine separate VisualStudio-Erweiterung verwendet. Im neuen .csproj-Format ist nun die Möglichkeit eingeführt worden, dass man standardmäßig direkt aus dem CSharp-Projekt heraus auch die Nuget-Pakete erstellen kann. Genau dieses Features wollte ich hier auch direkt ausprobieren. Insgesamt hat das auch recht gut funktioniert, mit Ausnahme der Projekte für die Universal Windows Platform (UWP), doch näheres dazu unten im Artikel.
Mit Null umgehen
Durch den Artikel “Result-Pattern statt Exceptions” im Windows Developer Magazin [1] bin ich auf die Library Functional Extensions for C# [2] gestoßen. Zunächst fand ich das Result-Pattern auch als sehr interessanten Weg, mit verschiedenen erwarteten Fehlern umzugehen und wollte das direkt mal ausprobieren. Die verwiesene Library macht aber einiges mehr, für mich primär interessant ist das Problem mit den Null-Referenzen.
ASP.Net Core mit OpenUI5 – DataBinding
In diesem zweiten Artikel zum Thema ASP.Net Core mit OpenUI5 gehe ich im Gegenteil zum letzten Artikel wieder einen Schritt zurück. Es geht hier erstmal um die Erstellung einer Seite mit Eingabe- und Ausgabefeldern – Im Beispiel in Form einer Konfigurationsseite. Für mich interessant an der Stelle ist das DataBinding von OpenUI5 und der Umgang mit den Datentypen von .Net. Strings und Zahlen sind ja i. d. R. kein Problem, interessanter wird es bei Enums oder Zeitstempel.
ASP.Net Core mit OpenUI5 – OData V4 Model
Es klingt schon nach einer sehr seltsamen Mischung, die aktuellste Version von ASP.Net Core mit OpenUI5 zu kombinieren. Doch genau mit dem Thema möchte ich mich momentan intensiver beschäftigen. Für diejenigen, die es nicht kennen: OpenUI5 ist die OpenSource-Variante des Frameworks SAPUI5. Es handelt sich dabei um ein JavaScript-Framework zur Erstellung von Business-Anwendungen primär für den Einsatz zusammen mit einem SAP-System. OpenUI5 enthält einen Großteil des Funktionsumfangs von SAPUI5, steht dagegen aber frei zur Verfügung.
Worklog SeeingSharp 2: Start
Für das Projekt Seeing# habe ich bereits sehr viele Stunden investiert. Begonnen mit dem 3D-Rendering ist das Framework über die Jahre sehr in die Breite gewachsen, etwa mit der Unterstützung für Video mit der Media Foundation oder einfachen Funktionen zur Wiedergabe von Musik und kurzen Sounds. Zudem habe ich öfters allgemeine Infrastruktur-Themen wie einen kleinen DI-Container, Übersetzungsfunktionen, etc. integriert. Der ursprüngliche Fokus auf 3D-Rendering ist dabei zum Teil stark verwässert. Aus diesem und anderen Gründen (siehe unten) habe ich mich dazu entschieden, einen größeren Breaking-Change zu machen und die Library grundsätzlich zu überarbeiten. Das Projekt befindet sich auf Github im Repository: https://github.com/RolandKoenig/SeeingSharp2. Bis Seeing# 2 aber die gleiche Funktionalität wie vorher Seeing# bietet, ziehen noch einige Wochen ins Land.
Automatisierte Tests mit Windows.Forms UI
Vor kurzem wurde ich auf einen kleinen aber blöden Fehler in Seeing# hingewiesen. Die Rendering-Hauptschleife ist abgebrochen, sobald man ein Windows.Forms Control von einem Parent ab und an einen anderen angehängt hat. Jetzt klingt das nach einem sehr seltenen Fall, aber auch diesen hätte ich ein paar Jahre zuvor explizit behandelt – allerdings im Rahmen eines Windows.Forms Programms. Im Laufe der Zeit ist dieser Fehler wieder in den Code gewandert, ohne dass er wirklich auffällt. Wer testet sowas auch immer wieder? Aus diesem Grund habe ich versucht, diesen Fall per Testautomatisierung zu behandeln, um so automatisch genau diesen Fall immer wieder abprüfen zu lassen.
SeeingSharp auf der XBox One!
Seit jetzt schon ein paar Monaten ist es möglich, Universal Apps auf der XBox One zu deployen. Auf diese Weise ist es möglich, mit C# Apps für die XBox One zu erstellen. Somit wird es langsam Zeit, dieses Feature mit Seeing# zu testen, denn generell läuft Seeing# innerhalb einer Universal App absolut stabil und bietet alle Funktionen wie am Desktop.
Gemeinsame Icon-Bibliothek in größeren Desktop-Apps
Je umfangreicher Desktop-Apps werden, desto größer wird auch ein Problem, welches zumeist zu Beginn der Entwicklung unterschätzt wird: Wo werden Icons abgelegt, welche von verschiedenen Programmteilen verwendet werden? Viele verschiedene Programmteile und Module (und wie sie auch immer genannt werden…), bei denen jeweils lokal Icons abgelegt werden, können nach einigen Jahren stetiger Entwicklung für Chaos sorgen. Bei meinen Projekten verstärkt sich das Problem zusätzlich aufgrund der Tatsache, dass sich ältere Windows.Forms- und neuere WPF-Komponenten mischen.