DirectX-Programmierung

In Windows 8.1 wird DirectX 11.2 eingeführt. Diese Version enthält zahlreiche neue Features für eine bessere Leistung in Ihren Spielen und Grafik-Apps.

Neues oder Aktualisierungen in Windows 8.1

HLSL-Shaderverknüpfung

[Laden Sie sich gleich jetzt das HLSL-Shader-Compiler-Beispiel herunter.]

Windows 8.1 bietet die separate Kompilierung und Verknüpfung von HLSL-Shadern. Dies ermöglicht Grafikprogrammierern das Erstellen vorkompilierter HLSL-Funktionen, das Packen dieser Funktionen in Bibliotheken und das Verknüpfen mit vollständigen Shadern zur Laufzeit. Dies entspricht im Wesentlichen der separaten C/C++-Kompilierung und -Verknüpfung sowie den zugehörigen Bibliotheken. Programmierer können so vorkompilierten HLSL-Code erstellen, wenn weitere Informationen zum Fertigstellen der Berechnung zur Verfügung stehen.

Programmierer führen zum Erstellen des endgültigen Shaders mehrere Schritte aus und verwenden dazu die dynamische Verknüpfung zur Laufzeit:

  • Erstellen eines ID3D11Linker-Linker-Objekts, das einen Verknüpfungskontext darstellt. Mit einem einzelnen Kontext können nicht mehrere Shader erstellt werden. Mit einem Verknüpfungskontext wird ein einzelner Shader generiert, und anschließend wird der Verknüpfungskontext gelöscht.

  • Verwenden Sie D3DLoadModule, um Bibliotheken aus den Bibliotheks-BLOBs zu laden und festzulegen.

  • Verwenden Sie D3DLoadModule, um ein Einstiegsshader-BLOB zu laden oder festzulegen bzw. einen FLG-Shader (siehe nächster Abschnitt) zu erstellen.

  • Mithilfe von ID3D11Module::CreateInstance können Sie ID3D11ModuleInstance-Objekte erstellen und anschließend Funktionen für diese Objekte aufrufen, um Ressourcen neu an ihre endgültigen Positionen zu binden.

  • Fügen Sie die Bibliotheken zum Linker hinzu, und rufen Sie dann ID3D11Linker::Link auf, um Bytecode für den endgültigen Shader zu generieren, der anschließend in den aktuellen D3D-Runtimes genau wie ein vollständig vorkompilierter und verknüpfter Shader geladen und verwendet werden kann.

Funktionsverknüpfungsdiagramm (Function Linking Graph, FLG)

Windows 8.1 bietet außerdem das Funktionsverknüpfungsdiagramm (Function Linking Graph, FLG). Mit dem FLG können Programmierer Shader erstellen, die aus einer Sequenz vorkompilierter Funktionsaufrufe bestehen, die sich gegenseitig Werte übergeben. Bei Verwendung des FLG müssen Sie weder HLSL-Code schreiben noch den HLSL-Compiler aufrufen. Stattdessen wird die Shaderstruktur programmatisch mit C++-API-Aufrufen angegeben. FLG-Knoten stellen Eingabe- und Ausgabesignaturen und Aufrufe vorkompilierter Bibliotheksfunktionen dar. Die Reihenfolge beim Registrieren der Funktionsaufrufknoten definiert die Sequenz der Aufrufe. Der Eingabesignaturknoten muss als erstes angegeben werden, der Ausgabesignaturknoten hingegen zuletzt. FLG-Kanten definieren, wie Werte zwischen Knoten übergeben werden. Die Datentypen übergebener Werte müssen gleich sein. Es gibt keine implizite Typkonvertierung. Die Regeln zum Formen und Swizzeln folgen dem HLSL-Verhalten. Werte können nur in dieser Reihenfolge übergeben werden. Informationen zur FLG-API finden Sie unter ID3D11FunctionLinkingGraph.

Integrierter HLSL-Compiler

[Laden Sie sich gleich jetzt das HLSL-Shader-Compiler-Beispiel herunter.]

Der HLSL-Compiler ist nun in Windows 8.1 und höheren Versionen integriert. Die meisten APIs für die Shaderprogrammierung können nun in Windows Store-Apps verwendet werden, die für Windows 8.1 und höhere Versionen erstellt werden. Viele APIs für die Shaderprogrammierung konnten in für Windows 8 erstellten Windows Store-Apps nicht genutzt werden. Die Verweisseiten für diese APIs waren mit einem Hinweis gekennzeichnet. Manche Shader-APIs (z. B. D3DCompileFromFile) können immer noch lediglich zum Entwickeln von Windows Store-Apps, aber nicht in Apps verwendet werden, die Sie an den Windows Store übermitteln. Die Verweisseiten für diese APIs enthalten weiterhin einen Hinweis.

GPU-Überlagerungsunterstützung

[Sichern Sie sich gleich jetzt die DirectX-Vordergrund-Swapketten.]

Dank der Unterstützung für GPU-Überlagerung mit mehreren Ebenen werden Ihre kunstvollen 2D-Grafiken und -Oberflächen bei der systemeigenen Auflösung auf bestmögliche Weise dargestellt, während Sie die 3D-Szenen in einem kleineren, skalierten Framepuffer zeichnen. Ermitteln Sie mit der neuen IDXGIOutput2::SupportsOverlays-Methode, ob die Plattform mehrere Zeichenebenen unterstützt. Erstellen Sie eine Überlagerungsswapkette, indem Sie das DXGI_SWAP_CHAIN_FLAG_FOREGROUND_LAYER-Kennzeichen (siehe DXGI_SWAP_CHAIN_FLAG) festlegen.

Dieses Feature ermöglicht die automatische Skalierung und Komposition von zwei Swapketten für die Hardware für Überlagerungen mit festen Funktionen ohne jegliche Verwendung von GPU-Ressourcen. Dadurch sind mehr GPU-Ressourcen für den App-Renderingcode verfügbar. Apps können mithilfe von Code verschiedene Auflösungen rendern. Dazu sind jedoch zusätzliche Kopien und Kompositionsdurchläufe erforderlich, die für Plattformen mit niedriger Leistung nicht ideal sind.

Mit der IDXGISwapChain2::SetSourceSize-API ändern Sie die Größe der unteren 3D-Swapkette auf eine niedrigere Auflösung als die systemeigene Auflösung und erstellen eine neue Swapkette für den Vordergrund mit systemeigener Auflösung, die den 2D-Inhalt enthält. Auf diese Weise steuern Sie die Größenanpassung für beide Swapketten.

Unterteilte DirectX-Ressourcen

[Laden Sie sich gleich jetzt das Beispiel für unterteilte Direct3D-Ressourcen herunter.]

Windows 8.1 enthält das neue Direct3D-Feature für unterteilte Ressourcen. Es macht ein Modell für einen eingeschränkten virtuellen Grafikspeicher für Apps verfügbar und ermöglicht dadurch die lose Zuordnung zwischen logischen Ressourcendaten und physischem Speicher. So können Sie umfassende logische Ressourcen erstellen, die wenig physischen Speicher belegen. Dies ist u. a. für Gelände in Spielen und für die App-UI nützlich.

Unterteilte Ressourcen werden durch Angabe des D3D11_RESOURCE_MISC_TILED-Flags erstellt. Die folgenden API-Funktionen können Sie zum Arbeiten mit unterteilten Ressourcen verwenden: UpdateTiles, UpdateTileMappings und GetResourceTiling.

Unterstützung für das DirectX-Feature für unterteilte Ressourcen

Bevor Sie das Feature für unterteilte Ressourcen verwenden können, müssen Sie ermitteln, ob das Gerät unterteilte Ressourcen unterstützt. Überprüfen Sie die Featureunterstützung für unterteilte Ressourcen wie folgt:


HRESULT hr = D3D11CreateDevice(
    nullptr,                    // Specify nullptr to use the default adapter.
    D3D_DRIVER_TYPE_HARDWARE,   // Create a device using the hardware graphics driver.
    0,                          // Should be 0 unless the driver is D3D_DRIVER_TYPE_SOFTWARE.
    creationFlags,              // Set debug and Direct2D compatibility flags.
    featureLevels,              // List of feature levels this app can support.
    ARRAYSIZE(featureLevels),   // Size of the list above.
    D3D11_SDK_VERSION,          // Always set this to D3D11_SDK_VERSION for Windows Store apps.
    &device,                    // Returns the Direct3D device created.
    &m_d3dFeatureLevel,         // Returns feature level of device created.
    &context                    // Returns the device immediate context.
    );

if (SUCCEEDED(hr))
{
    D3D11_FEATURE_DATA_D3D11_OPTIONS1 featureData;
    DX::ThrowIfFailed(
        device->CheckFeatureSupport(D3D11_FEATURE_D3D11_OPTIONS1, &featureData, sizeof(featureData))
        );

    m_tiledResourcesTier = featureData.TiledResourcesTier;
}

API für die Direct3D-Darstellung mit geringer Latenz

[Laden Sie das DirectXLatency-Beispiel jetzt herunter.]

Windows 8.1 enthält einen neuen Satz APIs für DirectX-Apps, um Frames mit geringerer Latenz darzustellen. Dadurch wird eine schnellere UI-Reaktion ermöglicht. Mithilfe der neuen APIs können Apps auf die Darstellung durch die DXGI-Swapkette warten. So muss nicht die Swapkette auf die App warten. Wie beim vorhandenen Verhalten für das Blockieren bei der Darstellung kann die Framelatenz mithilfe von API-Aufrufen angepasst werden.

Verwenden der API für die Darstellung mit geringer Latenz

Programmierer können die API für die Darstellung mit geringer Latenz wie folgt verwenden:

  • Erstellen Sie die Swapkette mit dem DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT-Flag.

    
    DXGI_SWAP_CHAIN_DESC1 swapChainDesc = {0};
    swapChainDesc.Flags = DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT; // Enable GetFrameLatencyWaitableObject().
    
    
  • Mit dem DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT-Kennzeichen erstellte Swapketten verwenden statt der dem DXGI-Gerät zugeordneten Einstellung ihre eigene Einstellung für die Latenz pro Swapkette. Die Standardlatenz pro Swapkette ist 1. Dadurch wird sichergestellt, dass DXGI jeweils nur einen Frame in die Warteschlange verschiebt. Diese beiden Punkte verringern die Latenz und stellen sicher, dass die App erst nach den einzelnen VSync-Vorgängen rendert. Dadurch wird der Stromverbrauch minimiert.

    Die Latenzeinstellung und der Parallelisierungsgrad von CPU-/GPU-Aufgaben beeinflussen sich gegenseitig. Überschreiten die serialisierten CPU- und GPU-Aufgaben 17 Millisekunden (ms), sollte die Framelatenz in 2 geändert werden. Mit dieser Einstellung bleibt genug Zeit zum Parallelisieren der CPU-/GPU-Aufgaben. Wenn von Ihrer App mehr als 17 ms für Aufgaben pro Frame benötigt werden, stellen Sie die Latenz auf 2 ein, indem Sie SetMaximumFrameLatency aufrufen.

    
    DX::ThrowIfFailed(
        m_swapChain->SetMaximumFrameLatency(2)
        );
    
    

    Rufen Sie anschließend GetFrameLatencyWaitableObject auf, um das Objekt mit Wartemöglichkeit für die Framelatenz der Swapkette abzurufen.

    
    m_frameLatencyWaitableObject = m_swapChain->GetFrameLatencyWaitableObject();
    
    

    Rufen Sie in der Renderschleife am Anfang jeder Schleife unbedingt WaitForSingleObjectEx auf. Dadurch wird sichergestellt, dass die App wartet, bis die Swapkette für neue Renderaufgaben verfügbar ist, bevor die App mit dem Rendern der einzelnen neuen Frames beginnt.

    
    DWORD result = WaitForSingleObjectEx(
        m_frameLatencyWaitableObject,
        1000, // 1-second timeout (shouldn't ever occur)
        true
        );
    
    

Rahmenpufferskalierung

Dank der neuen GPU-Skalierung können Sie die Größe des Rahmenpuffers dynamisch ändern, damit Ihre 3D-Grafiken flüssig wiedergegeben werden. In der neuen IDXGISwapChain2-Schnittstelle wird eine Reihe von neuen Methoden definiert, um die Größe der Swapkette der Quelle abzurufen und einzustellen und die Skalierungsmatrix für den Rahmenpuffer festzulegen.

DXGI-Kürzungs-API und Zuordnungsstandardpuffer

[Laden Sie sich gleich jetzt das DXGI-Swapketten-Drehungsbeispiel herunter.]

Windows 8.1 beinhaltet die neue DXGI-IDXGIDevice3::Trim-Methode, die es möglich macht, dass DirectX-Apps vom Grafiktreiber zugewiesenen Gerätespeicher freigeben. Dadurch wird das Speicherprofil der App im angehaltenen Zustand reduziert.

Darüber hinaus enthält Windows 8.1 einen neuen Zuordnungsstandardpuffervorgang für Direct3D-Apps, mit dem Ihre App direkt auf die Standardpuffer einer GPU zugreifen kann (sofern dies vom Gerät unterstützt wird), ohne dass ein aufwendigerer Zwischenkopiervorgang in einen temporären Puffer erforderlich ist.

Multithreading mit "SurfaceImageSource"

[Laden Sie sich gleich jetzt das SurfaceImageSource-Beispiel für DirectX/XAML-Interoperabilität herunter.]

In Windows 8.1 können Apps außerdem aus einem Hintergrundthread auf SurfaceImageSource (SIS)-XAML-Elemente zugreifen und sie aktualisieren.

Apps können nun ISurfaceImageSourceNativeWithD2D::BeginDraw aus einem beliebigen Thread aufrufen. Die neuen Methoden ISurfaceImageSourceNativeWithD2D:SuspendDraw und ISurfaceImageSourceNativeWithD2D:ResumeDraw können dementsprechend Apps das Anhalten des Zeichenvorgangs für einen Thread und das Fortsetzen des Vorgangs für einen anderen Thread ermöglichen.

Damit Sie das Multithreading nutzen können, muss Ihre App die folgenden Bedingungen erfüllen:

  • Für die folgenden Objekte (sofern sie verwendet werden) muss Multithreading verwendet werden:
  • Die App ruft BeginDraw, SuspendDraw und ResumeDraw für alle Threads auf, EndDraw jedoch nur für den XAML-UI-Thread. Beachten Sie, dass Apps vor dem Aufrufen von EndDraw nicht ResumeDraw aufrufen müssen und alle im selben XAML-UI-Threadtakt gesendeten EndDraw-Aktualisierungen auch im selben Frame übermittelt werden.

In diesem Codebeispiel sehen Sie, wie Sie Multithreading mit einem SurfaceImageSource-Element verwenden.

// Create a SIS element and associate a multithreaded DirectX device
ComPtr<ISurfaceImageSourceNativeWithD2D> m_sisNative;

// ...

m_sisNative->SetDevice1(m_d3dDevice.Get());

POINT offset;
ComPtr<IDXGISurface> surface;

// Begin drawing.
HRESULT beginDrawHR = m_sisNative->BeginDraw1(
updateRect, IID_IDXGISurface, &surface, &offset);

// QI for target texture from DXGI surface.
ComPtr<ID3D11Texture2D> d3DTexture;
surface.As(&d3DTexture);

// Create render target view.
m_d3dDevice->CreateRenderTargetView(d3DTexture.Get(), nullptr,   
  &m_renderTargetView); 

// Render complex content.
// ...

// Suspend drawing before signaling the UI thread.
m_sisNative->SuspendDraw();

// Signal the UI thread that drawing is complete, so EndDraw() can be called.
// ...

// Call EndDraw() on the UI thread to commit changes for the current frame.
m_sisNative->EndDraw();

Wichtige Punkte zu den neuen Methoden ISurfaceImageSourceNative1::SetDevice1 und ISurfaceImageSourceNative1::BeginDraw1:

  • Im Gegensatz zu SetDevice() akzeptiert SetDevice1() alternativ ein ID2D1Device-Element anstelle eines IDXGIDevice-Elements. Dies ist für die Unterstützung der oberflächenübergreifenden Direct2D-Batchverarbeitung erforderlich.

  • Die neue BeginDraw1()-Überladung gibt einen Gerätekontext zurück, statt direkt eine Entwurfsoberfläche zurückzugeben, falls ein Direct2D-Gerät an SetDevice übergeben wurde.

Interaktive DirectX-Komposition von visuellen XAML-Elementen

[Laden Sie sich gleich jetzt das SwapChainPanel-Beispiel für DirectX/XAML-Interoperabilität herunter.]

Sie können die SwapChainPanel-Klasse in Windows 8.1 verwenden, um DirectX-Grafikinhalt in einer App wiederzugeben, die XAML verwendet – und dies mit besserer Leistung und geringerer Latenz als bei der Verwendung der SurfaceImageSource-Klasse in Windows 8. Gleichzeitig gibt es weniger Layouteinschränkungen als bei der Verwendung der SwapChainBackgroundPanel-Klasse.

SwapChainPanel ähnelt SwapChainBackgroundPanel in Windows 8. Allerdings liegen weniger Einschränkungen bei XAML-Strukturplatzierung und -verwendung vor. (SwapChainBackgroundPanel war auf die Vollbilddarstellung und die Platzierung hinter dem gesamten XAML-Inhalt in der Elementanzeigestruktur beschränkt).

SwapChainPanel unterstützt folgende Anzeigeoptionen:

  • Beliebige Größen, Transformationen und Deckkraftstufen

  • Überlappung mit anderen visuellen Elementen in der XAML-Struktur

  • Scrollen mit dem ScrollViewer-Steuerelement

Ihre App kann außerdem mehrere Swapketten enthalten, die jeweils die Darstellung für ein einzelnes SwapChainPanel-Element bereitstellen. Beachten Sie jedoch, dass die Leistung vielleicht abnimmt, wenn viele Swapketten gleichzeitig aktualisiert werden. Die App sollte daher höchstens vier Swapketten verwenden.

SwapChainPanel-Objekte werden wie andere XAML-Elemente an einer beliebigen Position in der Elementstruktur und in beliebiger Größe deklariert.

Hier wird erläutert, wie Sie ein SwapChainPanel-Element in Ihrer XAML-Seite deklarieren.


<Page>
  <Grid>
    <SwapChainPanel x:Name=”mySwapChainPanel” Height=”300” Width=”400” />
    <!-- Additional XAML code ..>
</Grid>
</Page>


Wie beim SwapChainBackgroundPanel-Element erstellen Apps eine Sicherungsswapkette, indem sie die IDXGIFactory2::CreateSwapChainForComposition-Methode aufrufen und sie einer Instanz von SwapChainPanel zuordnen. Sie nehmen die Zuordnung mithilfe eines intelligenten Zeigers für die ISwapChainPanelNative-Schnittstelle vor.

Diese Bedingungen gelten für die erstellte Swapkette:

  • Die Swapkette kann eine beliebige Größe aufweisen, die von Microsoft DXGI (DirectX Graphics Infrastructure) als gültig erachtet wird.

  • Die Swapkette wird bei einer Größenänderung durch den Benutzer nicht gestreckt. Stattdessen ähnelt das Größenänderungsverhalten dem Festlegen von Stretch=None für ein Image-Element.

  • Apps können eine Swapkette (über die ISwapChainPanelNative::SetSwapChain-Methode) nur für den UI-Hauptthread (CoreWindow) zuordnen.

  • Eine einzelne Swapkette kann mehreren SwapChainPanels-Elementen zugeordnet werden. Sofern die Bedingungen für DirectX-Multithreading erfüllt sind, können Apps in beliebigen Intervallen in die Swapkette rendern oder diese im UI-Thread oder in einem Hintergrundthread darstellen.

In diesem Codebeispiel sehen Sie, wie Sie eine Swapkette einer SwapChainPanel-Instanz zuordnen.


ComPtr<ISwapChainPanelNative> panelNative;
 
reinterpret_cast<IUnknown*>(mySwapChainPanel)->QueryInterface(IID_PPV_ARGS(&panelNative));
panelNative->SetSwapChain(m_swapChain.Get());



Direct2D-Batchverarbeitung mit "SurfaceImageSource"

[Laden Sie sich gleich jetzt das SurfaceImageSource-Beispiel für DirectX/XAML-Interoperabilität herunter.]

Unter Windows 8.1 können Apps mehrere SurfaceImageSource (SIS)- und VirtualSurfaceImageSource (VSIS)-XAML-Elemente aktualisieren, ohne dass ein separater Direct2D-Batchvorgang für die einzelnen Aktualisierungen erforderlich ist.

Apps können dieses neue Batchverarbeitungsverhalten nutzen, indem Sie die QueryInterface-Methode aufrufen und einen Zeiger für die neue ISurfaceImageSourceNativeWithD2D-Schnittstelle abrufen.

Wie bei anderen DirectX-zu-XAML-Interoperabilitäts-APIs handelt es sich hier um systemeigene COM-Schnittstellen und nicht um Windows-Runtime-APIs, da sie direkt mit den DirectX-APIs zusammenarbeiten. Nach dem Zugreifen auf die neuen Schnittstellen können Apps die SetDevice1-Methode für die einzelnen Schnittstellen aufrufen und ein ID2D1Device- oder ein IDXGIDevice-Objekt übergeben.

Gibt die App ein Direct2D-Gerät an, weist dies darauf hin, dass SIS die Batchverarbeitung von Direct2D-Aufrufen unterstützen sollte. Wenn BeginDraw für die ISurfaceImageSourceNativeWithD2D-Schnittstelle aufgerufen wird, erhält die App ein ID2D1DeviceContext-Objekt anstelle eines IDXGISurface-Objekts. Geben Sie dieses Gerät für das XAML-Framework an. Dieses erstellt dann die entsprechende Oberfläche. Für alle für ID2D1DeviceContext ausgestellten Zeichenbefehle wird dann mit Direct2D-Zeichenbefehlen eine Batchverarbeitung (wenn möglich) für alle anderen SIS-Elemente ausgeführt, die:

Dieses Verhalten ist am besten geeignet, wenn eine App zwei SIS-Elemente mit Direct2D-Inhalt gleichzeitig aktualisiert. Die App verwendet die neue Batchverarbeitungsfunktion zum Teilen des Direct2D-Geräts und Kontexts und verhindert so das Löschen von Direct2D-Batches zwischen den einzelnen SIS-Aktualisierungen. Das Verringern der CPU-Auslastung steigert die Leistung.

Der folgende Code veranschaulicht, wie diese Aktionen ausgeführt werden.

// Create SIS elements and associate a multithreaded DirectX device.
ComPtr<ISurfaceImageSourceNativeWithD2D> m_sisNative1;
ComPtr<ISurfaceImageSourceNativeWithD2D> m_sisNative2;

// ...

m_sisNative1->SetDevice1(m_d3dDevice.Get());
m_sisNative2->SetDevice1(m_d3dDevice.Get());

// Set device for both SIS elements.
m_sisNative1->SetDevice(m_d2dDevice.Get());
m_sisNative2->SetDevice(m_d2dDevice.Get());

POINT offset;
ComPtr<ID2D1DeviceContext> d2dContext;

// Begin drawing SIS #1. 
HRESULT beginDrawHR = m_sisNative1->BeginDraw(
updateRect, IID_ID2D1DeviceContext, &d2dContext, &offset);
 
if (beginDrawHR == DXGI_ERROR_DEVICE_REMOVED || 
    beginDrawHR == DXGI_ERROR_DEVICE_RESET)
{ // Error checking }

// App does not call BeginDraw/EndDraw on Direct2D context;
// this is managed by the framework.

// Issue Direct2D drawing commands for SIS #1.
d2dContext->FillRectangle(D2D1::RectF(0,0,10,10), m_brush1.Get());

// Begin drawing SIS #2. 
beginDrawHR = m_sisNative2->BeginDraw(
updateRect, IID_ID2D1DeviceContext, &d2dContext, &offset);
 
if (beginDrawHR == DXGI_ERROR_DEVICE_REMOVED || 
    beginDrawHR == DXGI_ERROR_DEVICE_RESET)
{ // Error checking. }

// Issue Direct2D drawing commands for SIS #2.
d2dContext ->FillRectangle(D2D1::RectF(20,20,30,30), m_brush2.Get());

Hinweis  Hier finden Sie einige zusätzliche Tipps:

  • Vermeiden Sie im Allgemeinen das Aufrufen von ISurfaceImageSourceNativeWithD2D::BeginDraw oder ISurfaceImageSourceNative::EndDraw (bzw. der entsprechenden VSIS-Methoden) bei der Batchverarbeitung von Aktualisierungen, da dabei die Direct2D-Batches unterteilt werden.

  • Speichern Sie das von ISurfaceImageSourceNativeWithD2D::BeginDraw zurückgegebene ID2D1DeviceContext-Element nicht zwischen, wenn Sie anstelle einer DXGI-Oberfläche einen Direct2D-Kontext anfordern.

  • Direct2D- und Direct3D-Zeichenvorgänge dürfen sich nicht überlappen, da dadurch die einzelnen Sätze mit Direct2D-Aufgaben den aktuellen Batch leeren. Direct2D- und Direct3D-Aufgaben sollten separat und der Reihe nach angeordnet werden.

 

 

Anzeigen:
© 2014 Microsoft