a) Einleitung

Im folgenden werden allgemeine Ideen gesammelt, die in Betriebssystemen zur Beschleunigung von Multimedia-Anwendungen eingesetzt werden können.[1] Microsoft veröffentlicht leider kaum Dokumentationen darüber, ob und gegebenenfalls wie diese Konzepte in DirectX umgesetzt wurden.

 

b) Direkte Ansprache

Generell gilt: je direkter von der Anwendung auf die Hardware zugegriffen werden kann, desto schneller arbeitet sie. Ein solcher direkter Zugriff kann etwa um einen Faktor 1000-10000 schneller sein (siehe Beispiel „Buchstaben färben“ oben).

 

c) Hardwarenahe Programmierung durch Umgehen nicht benötigter Bestandteile

Dies wurde z.B. auf dem Amiga bei der Spieleprogrammierung gemacht. Dabei wurden Teile des Betriebssystems durch eigene Routinen ersetzt, welche speziell auf die Problemlösung zugeschnitten waren. Diese ließen überflüssige Teil weg und waren damit schneller und kleiner.

 

d) Dynamische Daten statisch machen

Weitere Zeitersparnis ist dadurch möglich, dass sich ändernde Daten wie Fensterkoordinaten und –grenzen, nicht bei jeder Aktion neu berechnet werden, sondern für unbestimmte Zeit als statisch angesehen werden. Ändern sich die Werte z.B. bei einem Task-Wechsel, bekommt das Programm eine Fehlermeldung und muß sich um die Neuberechnung selbst kümmern. Das Betriebssystem wird dadurch entlastet, dass es sich nicht selbst ständig um die Berechnung kümmern muß.

 

e) Datenmodelle für direktes Arbeiten auf der Hardware

Grafik- und Audiodaten können normalerweise von Windows-Anwendungen in einem beliebigen Standardformat an Windows übergeben werden, welches dann automatisch für die korrekte Ausgabe über die vorhandene Hardware sorgt. Hier entsteht ein großer Overhead, da Windows selbst die Formatwandlung für die Hardware durchführt. Dies ist zwar für den Programmierer praktisch, aber bremst das Betriebssystem aus.

Dieser Overhead kann dadurch vermieden werden, dass das Programm selbst die Daten zunächst in das korrekte von der Hardware verstandene Format bringt und die Hardware dann direkt anspricht. Zwar muß ein solches Programm unter Umständen mehrere Routinen für verschiedene Grafik- und Audioformate (z.B. 8 Bit, 16 Bit, 24 Bit, 32 Bit Daten) haben. Dies ist jedoch vom Programmieraufwand immer noch weniger als die oben beschriebene Treiberprogrammierung unter MS-DOS.

 

f) Multitasking und das Pseudo-Ein-Prozess-System

Windows ist ein Multitasking-Betriebssystem, d.h. mehrere Prozesse können theoretisch gleichzeitig laufen, wenn sie auch praktisch durch den Scheduler in kleinen Stücken nacheinander abgearbeitet werden.

Um dieses Multitasking zu realisieren, entsteht dadurch, dass jeder Prozess jede seiner einzelnen Aktionen beim Betriebssystem anmelden muß und Ressourcen immer wieder erneut belegt und initialisiert werden müssen, ein großer Overhead. Bei Threads entsteht immerhin noch ein kleiner Overhead.

 

Grafik: Jeder Prozeß muß seine Aktionen anmelden und bekommt dann vom Scheduler Arbeitszeit zugeteilt.

Quelle: http://www.tecchannel.de/multimedia/81/index.html

 

Dieser Overhead kann durch ein Pseudo-Einprozess-System vermieden werden. Bei einem solchen System fordert ein Prozess beim Betriebssystem eine Ressource auf unbeschränkte Zeit an. Das System nimmt dabei eine Sicherung des aktuellen Zustandes vor. Die Ressource bleibt dann solange im Besitz des Prozesses, bis der nächste Prozess die Ressource anfordert. Im Gegensatz zu einem gewöhnlichen Multitasking-System muß der Zustand einer Ressource also nicht nach jeder Einzelaktion, sondern erst nach der nächsten Anforderung der Ressource wiederhergestellt werden.

 

 

Grafik: Pseudo-Einprozess-System:

Hier fordert Prozess A die Ressource an und verwendet sie. Prozess B verwendet die selbe Ressource zwischenzeitlich. Prozess A wird dann ein Fehler gemeldet und er muß die Ressource erneut anfordern und initialisieren.

Quelle: http://www.tecchannel.de/multimedia/81/index.html

 

Eine einfache Umsetzung dieses Prinzips enthielt bereits der Vorgänger von DirectX – das Microsoft Game SDK von 1994. Es ermöglichte einem Prozess aus Windows heraus in den Vollbildmodus zu schalten und diesen Prozess bis zu einem expliziten Task-Wechsel als Einprozess-System zu behandeln. Dieses GameSDK war zwar insofern revolutionär als es dem Windows-Multitasking-Gedanken widersprach. Es war aber strukturell dem ersten DirectX noch weit unterlegen, da es außer diesem Vollbildmodus kaum nennenswerte Features besaß.