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.
Problem an diesem Synchronisierungs-Thema ist nicht nur grundsätzlich, dass das Vorgehen in Form von benötigten Methodenaufrufen, Interfaces und Klassen anders ist, sondern auch beim Threading sind andere Themen zu beachten. SeeingSharp (Arbeitstitel der 3D-Engine) arbeitet grundsätzlich im Hintergrund und verteilt sich komplett über den ThreadPool. In Bezug auf das Windows Phone ist das zwar erst einmal kein Problem, bei der Synchronisierung mit der Xaml-Oberfläche sind damit aber 3 Threads beteiligt: Der Gui-Thread, der Render-Thread von SeeingSharp und der Xaml-Renderer (Render-Thread der Xaml-Oberfläche). Vom Gui-Thread kommen diverse Standard-Meldung wie etwa Größenänderungen des Controls. Der Render-Thread von SeeingSharp steuert grundsätzlich die eigene 3D-Render-Logik und der Xaml-Renderer rendert entsprechend die Xaml-Elemente. Nun ist es so, dass eine gemeinsame Textur angelegt werden muss, in die SeeingSharp rendert und welche entsprechend in das Xaml eingebettet wird. Problem ist nur: Die Textur darf nur dann manipuliert werden, wenn es der Xaml-Renderer erlaubt. Insgesamt also ein leicht verzwicktes Thema, um es bei den ersten Tests stabil zu bekommen. Stabil bedeutet hier im “Normalbetrieb”, bei Größen- und Layout-Änderungen und bei der Navigation zwischen den Pages.