Heute früh habe ich mir ein paar Videos von der diesjährigen Build angesehen und bin dabei auf den Talk “Introducing Win2D” gestoßen [1]. Über diese API habe ich zwar schon vorher gelesen, habe sie mir bis jetzt aber noch nicht tiefer angeschaut, da ich Direct2D normalerweise per SharpDX direkt von C# aus verwende. Grundsätzlich finde ich es aber sehr gut, dass Microsoft selbst an einen Weg arbeitet, die Direct2D-API über Win2D auch für C#/.Net Entwickler verfügbar zu machen. Die Performance ist super und die API der von System.Drawing sehr ähnlich. Einzig die Tatsache, dass Win2D für Universal Apps ausgelegt ist, finde ich etwas schade. In Seeing# etwa binde ich auch Direct2D ein, mache das dann aber auch für Desktop-Plattformen, also Win.Forms, WPF und Universal/WinRT. Schnelles hardwarebeschleunigtes 2D-Rendering ist schließlich auch bei Desktop-Programmen interessant.
Multimedia
Wie schnell man Speicher falsch kopieren kann
Neulich habe ich hier auf der Homepage einen Eintrag über das Lesen von Frames aus einem Video per Media Foundation geschrieben. Die Sache hat super geklappt, nur spätestens bei größeren Videos ist aufgefallen, dass die Sache schon sehr langsam und ruckelig ist. Aus diesem Grund habe ich gestern und heute etwas tiefer rein geschaut und untersucht, wo dort überhaupt die Performance verloren geht. Denn, ganz ehrlich, Performance darf auf meinem Rechner mit I7 und aktueller Radeon R9 kein Problem sein. Das Thema musste also irgendwo in meinem Coding liegen. Der Haupt-Performance-Fresser war dann mithilfe einer Leistungsanalyse in Visual Studio auch sehr schnell gefunden: Ein paar for-Schleifen.
Videos per SourceReader der MediaFoundation lesen
Mein letzter Beitrag auf dieser Seite hatte das Schreiben von Videos per Media Foundation zum Thema, in diesem hier geht es entsprechend um das Lesen. Auch hier habe ich mich an die Vorlagen von Microsoft gehalten, beispielsweise dieses kurze Tutorial [1]. Die Klasse SourceReader der Media Foundation ist hierbei Dreh- und Angelpunkt. Mit ihr kann man eine neue Video-Datei anlegen und entsprechend alle Video-Frames einzeln übergeben. Alles nichts weltbewegendes, letzten Endes hat es mir aber trotzdem ein paar Tage gekostet, die Sache ordentlich zum Laufen zu kriegen. Wer denkt auch daran, dass Alpha-Werte vom SourceReader ignoriert werden?
Videos per SinkWriter der MediaFoundation schreiben
Aktuell arbeite ich in Vorbereitung für ein kommendes (Hobby-)Projekt wieder verstärkt mit der Media Foundation von MS. Erster Schritt war nun, per SinkWriter Videos direkt aus der 3D-Ansicht von Seeing# heraus schreiben zu können. Der zweite Schritt, Videos auch wieder auszulesen, ist noch in Arbeit [1]. Der SinkWriter ist eine Klasse der Media Foundation, welche dazu verwendet werden kann, von der Anwendung generierte Bilder direkt in eine Videodatei zu schreiben. Soll ein Video also etwa 30 Frames pro Sekunde haben, so kann die Anwendung eben diese 30 Frames pro Sekunde erzeugen und an den SinkWriter übergeben. Mein aktueller Stand ist damit der, dass ich direkt aus dem 3D-Rendering heraus nebenbei ein Video schreiben lassen kann.
Direct3D11, WPF und der Energiesparmodus
Direct3D 11 direkt in ein WPF D3DImage zu integrieren ist nicht ganz so einfach – das ist jedem bekannt, der das schon einmal probiert hat. Im Fall meiner 3D-Engine SeeingSharp gehe ich sogar noch etwas weiter: Das Rendering erfolgt komplett verteilt auf dem ThreadPool. Weiterhin werden so Kleinigkeiten wie Kantenglättung unterstützt, die die Integration in WPF auch noch etwas schwieriger machen. Nun habe ich es schon vor einer ganzen Weile geschafft, dass das auf allen getesteten Desktop-Rechnern gut funktioniert – aber irgendwie trifft man immer wieder auf neue Fälle. Neulich habe ich mir das neue Surface Pro 3 gekauft und siehe da… dort gibt es Probleme.
Portierung einer 3D-Engine auf Windows Phone #3
Vor einigen Wochen habe ich meinen 3D-Renderer auf Windows Phone 8.0 stabil zum Laufen bekommen und bin dabei auf die eine oder andere Hürde gestoßen. Da mittlerweile das Windows Phone 8.1 SDK verfügbar ist und auch SharpDX die entsprechenden Funktionen implementiert, konnte ich nun also einen neueren Weg ausprobieren – die Universal Apps. Vorteil: Dieser Weg verspricht, dass das Coding zwischen WinRT auf normalen Windows PCs und Windows Phone fast komplett identisch ist. Auch SharpDX verspricht, dass dieser Weg damit bereits gut funktioniert und nebenbei eine ganze Liste Nachteile der vorherigen Lösung ausbügelt.
Performance-Optimierung #1
Performance-Optimierung ist immer und überall ein Thema, welches viel Zeit und starke Nerven fordert. Zudem wird gerne an Stellen optimiert, welche für die Gesamtperformance letzten Endes nicht wirklich ausschlaggebend sind. Ich persönlich bin deswegen überwiegend der Meinung, während der Entwicklung selbst weniger auf Performance zu schauen und sich von Optimierungen nicht unnötig aufhalten zu lassen. Dort wo es hackt, kann im Nachhinein nachgebessert werden. Im Prinzip bin ich genauso bei der Entwicklung von SeeingSharp (Arbeitstitel für 3D-Engine) vorgegangen. Das Grundgerüst ist zunächst so aufgebaut, dass es aktuelle Anforderungen daran gut abdecken kann. Für künftige Aufgaben bin ich gerade dabei, an der Einen oder anderen Stelle zu schrauben, um so die nötige Leistung aus dem System zu bekommen. Die Schritte dazu und erste Ergebnisse erkläre ich kurz in diesem Beitrag.
Laden von Texturen auch auf Windows Phone
DirectX auf Windows Phone hat zwar zu einem großen Teil die gleiche API, wie auf dem Desktop, drum herum ist es aber z. T. stark eingeschränkt. Neben den Punkten aus den letzten Blog-Beiträgen (z. B. fehlendes Direct2D) hatte ich zusätzlich das Problem, dass ich bis jetzt fast durchweg png Dateien als Texturen verwendet habe. Grundsätzlich ja kein blöder Gedanke: Ein einfaches Dateiformat, welches man auch mit jedem Bildbearbeitungsprogramm bearbeiten und auch problemlos in eigenen Programmen verwenden kann. Auf dem Windows Phone funktioniert das aber nicht, da hierfür ausschließlich Texturen im dds Format zulässig sind. Daraus entstanden für mich im Wesentlichen zwei Probleme: Wie werden andere Dateiformate in dds konvertiert und wie können diese Dateien im Programm geladen werden?
Portierung einer 3D-Engine auf Windows Phone #2
Heute kam ich endlich einmal dazu, die Portierung auf Windows Phone wie im letzten Post beschrieben weiter zu machen. Kurzum: Das Ergebnis sieht mittlerweile sehr gut aus. Hürden gab es neben der zuletzt genannten zum Glück keine größeren mehr. Das einzig wirklich negative ist die Tatsache, dass die Synchronisierung zwischen Xaml-Rendering und Direct3D-Inhalt am Phone (natürlich) wieder anders ist, als auf allen anderen Windows Plattformen. Ich verwende den Weg über das DrawingSurface wie hier auf Msdn beschrieben.
Portierung einer 3D-Engine auf Windows Phone
Heute habe ich mich damit beschäftigt, eine 3D-Engine auf Windows Phone (8) zu portieren. Im Prinzip handelte es sich schon vor dieser Aktion um relativ viele Klassen, welche sauber auf Windows Desktop und WinRT laufen (auch ARM). Ich wusste zwar schon, dass die Phone-Plattform noch einmal deutlich eingeschränkter ist, als etwa die WinRT-Plattform für Tablets, das ich so viel rumbasteln muss, hätte ich aber nicht gedacht. Hier eine kurze Sammlung der Punkte, auf die ich gestoßen bin.