Architectuur en onderdelen

In dit onderwerp worden de onderdelen beschreven waaruit Microsoft DirectComposition bestaat. Deze bestaat uit de volgende secties.

• Software-onderdelen
• toepassingsbibliotheek
• samenstellingsmotor
• Verwante onderwerpen

Softwareonderdelen

DirectComposition bestaat uit de volgende hoofdsoftwareonderdelen.

• Een toepassingsbibliotheek in de gebruikersmodus (dcomp.dll) die op COM (Component Object Model) gebaseerde openbare API implementeert.
• Een samenstellingsengine in de gebruikersmodus (dwmcore.dll) die wordt gehost in het DWM-proces (Desktop Window Manager) (dwm.exe) en de daadwerkelijke bureaubladsamenstelling uitvoert.
• Een kernelmodusobjectdatabase (onderdeel van win32k.sys) die marshals opdrachten van de toepassing naar de samenstellingsengine uitvoert.

Eén exemplaar van de samenstellingsengine verwerkt de DirectCompositie-samenstellingsstructuren voor alle toepassingen en de DWM-samenstellingsstructuur, die het hele bureaublad vertegenwoordigt. Zowel de kernelmodusobjectdatabase als de samenstellingsengine van de gebruikersmodus worden eenmaal per sessie geïnstantieerd, dus een Terminal Server-machine met meerdere gebruikers heeft meerdere exemplaren van beide onderdelen.

In het volgende diagram ziet u de belangrijkste DirectCompositie-onderdelen en hoe deze zich verhouden tot elkaar.

Toepassingsbibliotheek

De DirectComposition-toepassingsbibliotheek is een openbare COM-API met één plat toegangspunt dat wordt geëxporteerd uit dcomp.dll en retourneert een interfaceaanwijzer naar een apparaatobject. Het apparaatobject heeft op zijn beurt methoden voor het maken van alle andere objecten, die elk worden vertegenwoordigd door een interfaceaanwijzer. Alle DirectComposition-interfaces nemen de IUnknown interface volledig over van en implementeer deze volledig. Alle methoden die DirectComposition-interfaces accepteren, controleren of de interface wordt geïmplementeerd in dcomp.dll of door een ander onderdeel wordt geïmplementeerd. Omdat DirectComposition niet uitbreidbaar is, retourneren methoden die interfaces als parameters gebruiken E_INVALIDARG als de interfaces niet in dcomp.dllworden geïmplementeerd. Voor de API zijn geen speciale bevoegdheden vereist; het kan worden aangeroepen door processen die worden uitgevoerd op het laagste toegangsniveau. Omdat de API echter niet werkt in sessie 0, is deze niet geschikt voor services. In dit opzicht is de DirectComposition-API vergelijkbaar met andere Microsoft DirectX-API's, met name Direct2D, Microsoft Direct3D en Microsoft DirectWrite.

Omdat de samenstellingsengine exclusief is ontworpen voor asynchrone uitvoering, zijn objecteigenschappen in de DirectComposition-API alleen-schrijven. Alle eigenschappen hebben settermethoden, maar geen getter-methoden. Leeseigenschappen zijn niet alleen resourceintensief, maar kunnen ook onnauwkeurig zijn omdat elke waarde die door de samenstellingsengine wordt geretourneerd, onmiddellijk ongeldig kan worden. Dit kan gebeuren als bijvoorbeeld een onafhankelijke animatie afhankelijk is van de eigenschap die wordt gelezen.

De API is thread-safe. Een toepassing kan elke methode op elk gewenst moment aanroepen vanuit elke thread. Omdat veel API-methoden echter in een bepaalde volgorde moeten worden aangeroepen, kan een toepassing zonder synchronisatie onvoorspelbaar gedrag ervaren, afhankelijk van hoe de threads worden opgeslagen. Als twee threads bijvoorbeeld dezelfde eigenschap van hetzelfde object wijzigen in verschillende waarden tegelijk, kan de toepassing niet voorspellen welke van de twee waarden de uiteindelijke waarde van de eigenschap is. Als twee threads Commit op hetzelfde apparaat aanroepen, krijgt geen van beide threads echt transactioneel gedrag omdat een aanroep naar Doorvoeren op één thread de batch met alle opdrachten verzendt die door beide threads worden uitgegeven, niet alleen het gesprek dat Doorvoerengenoemd.

Het systeem onderhoudt alle interne status per apparaatobject. Als een toepassing twee of meer DirectComposition-apparaatobjecten maakt, kan de toepassing onafhankelijke batches en andere status tussen de twee onderhouden.

Alle DirectComposition-objecten hebben apparaatobjectaffiniteit; objecten die door een bepaald apparaatobject worden gemaakt, kunnen alleen worden gebruikt met dat apparaatobject en kunnen alleen worden gekoppeld aan andere objecten die door hetzelfde apparaatobject worden gemaakt. Met andere woorden, elk apparaatobject is een afzonderlijk niet-aaneengesloten eiland van functionaliteit. De ene uitzondering is de visualklasse, waarmee het bouwen van visuele bomen wordt toegelaten waar een visual tot een ander apparaatobject kan behoren dan het bovenliggende object. Dit maakt scenario's mogelijk waarbij een toepassing en een besturingselement één samenstellingsstructuur kunnen beheren zonder dat u ook één DirectCompositie-apparaatobject hoeft te delen.

Samenstellingsengine

De DirectCompositie-samenstellingsengine wordt uitgevoerd op een speciaal proces, gescheiden van elk toepassingsproces. Eén samenstellingsproces, dwm.exe, ondersteunt elke toepassing in een sessie. Elke toepassing kan twee visuele structuren maken voor elk venster dat eigenaar is. Alle bomen worden eigenlijk geïmplementeerd als substructuren van een grotere visuele boom die ook de samenstellingsstructuren van DWM omvat. De DWM bouwt één grote visualstructuur voor elk bureaublad in een sessie. Dit zijn de belangrijkste voordelen van deze architectuur:

• De samenstellingsengine heeft toegang tot alle toepassings bitmaps en visuele structuren, waardoor interoperabiliteit en samenstelling tussen procesvensters mogelijk is.
• De samenstellingsengine wordt uitgevoerd in een vertrouwd systeemproces dat losstaat van elk toepassingsproces, waardoor toepassingen met weinig toegangsrechten veilig beveiligde inhoud kunnen opstellen.
• De samenstellingsengine kan detecteren wanneer een bepaald venster volledig is opgenomen en vermijd het verspillen van CPU- en GPU-resources (Graphics Processing Unit) die voor het venster zijn opgesteld.
• De samenstellingsengine kan rechtstreeks op de backbuffer van het scherm opstellen, waardoor er geen extra kopie nodig is voor samenstellingsmotoren per proces.
• Alle toepassingen delen één Direct3D-apparaat voor samenstelling, wat aanzienlijke geheugenbesparing biedt

De visuele structuur is een bewaarde structuur. De DirectComposition-API maakt methoden beschikbaar om de structuur te bewerken in batches met wijzigingen die atomisch worden verwerkt. Het hoofdobject in de DirectComposition-API is het apparaatobject, dat fungeert als de fabriek voor alle andere DirectCompositie-objecten en een methode bevat met de naam Commit. De samenstellingsengine geeft geen wijzigingen weer die de toepassing aanbrengt in de visualstructuur totdat de toepassing Doorvoerenaanroept, waarna alle wijzigingen sinds de laatste Commit als één transactie worden verwerkt.

De vereiste voor het aanroepen van Commit is vergelijkbaar met het concept van een frame, behalve dat, omdat de samenstellingsengine asynchroon wordt uitgevoerd, verschillende frames kan presenteren tussen aanroepen naar Commit. In DirectComposition is een frame één iteratie van de samenstellingsengine en het interval dat door een toepassing wordt besteed tussen twee aanroepen naar Commit wordt een batch-genoemd.

DirectComposition batcheert alle toepassingsoproepen naar de DirectComposition-API. De kernelobjectdatabase, die is geïmplementeerd in het win32k.sys sessiestuurprogramma, slaat alle statusinformatie op die is gekoppeld aan de API-aanroepen.

De samenstellingsmotor produceert één frame voor elke verticale lege waarde in het display. Het frame wordt gestart bij een verticale lege waarde en is gericht op de volgende verticale lege waarde. Wanneer het frame wordt gestart, haalt de samenstellingsengine alle in behandeling zijnde batches op en bevat de bijbehorende opdrachten in dat frame. Batches worden in een wachtrij geplaatst die in behandeling is wanneer de toepassing Doorvoerenaanroept en de wachtrij die in behandeling is, atomisch wordt leeggemaakt aan het begin van het frame. Daarom is er een enkel tijdstip dat het begin van een frame markeert. Alle batches die vóór dit punt worden ingediend, worden opgenomen in het frame, terwijl alle batches die na zijn ingediend, moeten wachten totdat het volgende frame is verwerkt. De volledige samenstellingslus is als volgt:

1. Schat de tijd van de volgende verticale waarde in.
2. Haal alle batches in behandeling op.
3. De opgehaalde batches verwerken.
4. Werk alle animaties bij met de geschatte tijd in stap 1.
5. Bepaal de regio's van het scherm die opnieuw moeten worden samengesteld.
6. Stel de vuile regio's opnieuw op.
7. Presenteer het frame door de achter- en voorbuffers voor elk scherm te spiegelen.
8. Als er niets is samengesteld en gepresenteerd in stap 6 en 7, wacht u tot een batch is doorgevoerd.
9. Wacht tot de volgende verticale waarde leeg is.

Als er meerdere monitors aan één videoadapter zijn gekoppeld, gebruikt de samenstellingsengine de verticale lege waarde van de primaire monitor om de samenstellingslus aan te sturen en de animatiesamplingtijden in te stellen. Elke monitor wordt vertegenwoordigd door een afzonderlijke flip-chain op volledig scherm; de samenstellingsmotor herhaalt stap 6 en 7 voor elke monitor, op round robin-wijze, met behulp van één Direct3D-apparaat. Als er ook meerdere videoadapters zijn, gebruikt de samenstellingsengine een afzonderlijk Direct3D-apparaat voor elke videoadapter in stap 6 en 7.

Samenstellingsframes worden gepland om altijd op een verticale lege waarde te beginnen, zoals in de volgende afbeelding wordt weergegeven.

Als de samenstellingsmotor geen werk heeft omdat de samenstellingsstructuur niet is gewijzigd, slaapt de samenstellingsthread terwijl wordt gewacht op een nieuwe batch. Wanneer een nieuwe batch wordt verzonden, wordt de samenstellingsthread wakker, maar gaat onmiddellijk terug naar de slaapstand totdat de volgende verticale lege. Dit gedrag zorgt voor voorspelbare begin- en eindtijden van frames voor toepassingen en voor de samenstellingsengine.

De samenstellingsengine publiceert de framepresentatietijden en de huidige framesnelheid. Door deze informatie te publiceren, kunnen toepassingen de presentatietijd schatten voor hun eigen batches, waardoor animaties op hun beurt kunnen worden gesynchroniseerd. Een toepassing kan met name een combinatie van framestatistieken van de samenstellingsengine gebruiken en een historisch model van hoelang de UI-thread nodig heeft om een batch te produceren, om de steekproeftijd voor zijn eigen animaties te bepalen.

Aan het begin van de toepassingsbatch die in de vorige afbeelding wordt weergegeven, kan de toepassing bijvoorbeeld een query uitvoeren op de samenstellingsengine om de exacte presentatietijd van het volgende frame te bepalen. De toepassing kan vervolgens de huidige tijd gebruiken, samen met informatie over eerdere batches die deze heeft geproduceerd, om te bepalen of de toepassing de huidige batch kan voltooien voordat de volgende verticale lege. Daarom gebruikt de toepassing de presentatietijd van het frame als de steekproeftijd voor zijn eigen animaties. Als de toepassing vaststelt dat het onwaarschijnlijk is om het werk in de huidige verticale lege waarde te voltooien, kan de toepassing de volgende frametijd gebruiken als de steekproeftijd, met behulp van de framesnelheidsinformatie die door de samenstellingsengine wordt geretourneerd om die tijd te berekenen.

Verwante onderwerpen

DirectComposition Concepts