@@ -117,9 +109,7 @@ title: '@samples.title'
-
- context.Capabilities.MeshShadingSupported
-
+
@@ -132,21 +122,6 @@ title: '@samples.title'
MeshShading.slang
-
-
-
-
-
- App.cs
- IRenderer.cs
-
-
-
-
- TexturePresenter.cs
- PresentTexture.slang
-
-
@@ -213,8 +188,3 @@ title: '@samples.title'
-
-
-
-
-
diff --git a/documents/locales/de-DE/strings.yml b/documents/locales/de-DE/strings.yml
index c4dea822..a8e2dd26 100644
--- a/documents/locales/de-DE/strings.yml
+++ b/documents/locales/de-DE/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: 'Ein {graphicsContext} verbindet die Anwendung über ein bestimmtes Backend mit einem GPU-Gerät und stellt dessen Grafik-, Compute- und Transferwarteschlangen bereit. Gemeinsam verwendete Ressourcen müssen demselben Kontext angehören: Puffer, Texturen, Shader, Pipelines und ihre Handles lassen sich nicht über Kontextgrenzen hinweg binden.'
+concepts.execution.context.description: 'Ein {graphicsContext} verbindet die Anwendung über die gewählte Grafik-API mit einem GPU-Gerät und stellt dessen Grafik-, Compute- und Transferwarteschlangen bereit. Gemeinsam verwendete Ressourcen müssen demselben Kontext angehören: Puffer, Texturen, Shader, Pipelines und ihre Handles lassen sich nicht über Kontextgrenzen hinweg binden.'
concepts.execution.context.details: '{capabilities} liefert den Gerätenamen und die unterstützten Funktionen. Prüfen Sie mit {rayTracingSupported} und {meshShadingSupported}, ob die jeweilige Funktion verfügbar ist, bevor Sie ihre Ressourcen erstellen. Die Beispiele für {link} und {detail} zeigen diese Prüfung bei der Initialisierung.'
concepts.execution.context.details.detail: Mesh-Shading
concepts.execution.context.details.link: Raytracing
@@ -17,7 +17,7 @@ concepts.execution.ownership.table.headings.object: Objekt
concepts.execution.ownership.table.headings.ownership: 'Verantwortung für die Freigabe'
concepts.execution.ownership.table.queues.object: 'Kontextwarteschlangen und ihre Timelines'
concepts.execution.ownership.table.queues.ownership: Der Kontext und die Warteschlangen verwalten sie.
-concepts.execution.ownership.table.swapChainDrawable.ownership: Die Swapchain verwaltet sie.
+concepts.execution.ownership.table.swapChainDrawable.ownership: Die Swapchain verwaltet diese Textur.
concepts.execution.ownership.title: 'Besitz und Lebensdauer'
concepts.execution.pipelines.description: 'Eine Grafikpipeline legt Shader, Vertex-Eingabelayout, Primitivzusammensetzung, Attachment-Formate und Renderzustand für Zeichenbefehle fest. Wählen Sie die Pipeline, bevor Sie Vertex-, Index- oder Konstantendaten binden. Attachment-Formate und Sample-Anzahl müssen mit dem Renderpass übereinstimmen.'
concepts.execution.pipelines.details: 'Eine Compute-Pipeline wählt den Shader-Einstiegspunkt für einen Dispatch. Binden Sie Pipeline und Konstanten vor dem Dispatch, außerhalb eines Grafik-Renderpasses.'
@@ -26,7 +26,7 @@ concepts.execution.pipelines.guidance.detail: Compute-Beispiel
concepts.execution.pipelines.guidance.link: Render-Callback des Dreiecks
concepts.execution.pipelines.title: 'Pipeline-Zustand'
concepts.execution.queues.description: '{graphicsQueue} ist der übliche Ausgangspunkt für Frames mit Zeichnen, Berechnungen und Kopien. Abhängige Operationen auf einer Warteschlange lassen sich einfacher anordnen.'
-concepts.execution.queues.details: 'Mit getrennten Warteschlangen lassen sich unabhängige Aufgaben getrennt einreichen. Daraus folgt jedoch nicht, dass ihnen unabhängige Hardwareeinheiten zugeordnet sind. Zusätzliche Warteschlangen sind sinnvoll, wenn Aufgaben von einer überlappenden Ausführung profitieren. Verwendet eine Warteschlange Daten aus einer anderen, benötigen ihre Einreichungen eine explizite Abhängigkeit.'
+concepts.execution.queues.details: 'Zusätzliche Warteschlangen können die überlappende Ausführung unabhängiger Aufgaben erleichtern, entsprechen aber nicht zwangsläufig unabhängigen Hardwareeinheiten. Nutzt eine Warteschlange Daten aus einer anderen, verbinden Sie ihre Einreichungen durch eine explizite Abhängigkeit.'
concepts.execution.queues.guidance: 'Auch innerhalb einer Warteschlange können abhängige Operationen Barrieren oder Texturübergänge benötigen, damit spätere Zugriffe die Ergebnisse früherer Schreibvorgänge sehen. Diese Speicherabhängigkeiten sind von der Einreichungsreihenfolge zu unterscheiden. Wie sie angegeben werden, erläutert {link}.'
concepts.execution.queues.guidance.link: Synchronisation
concepts.execution.queues.table.computeQueue.workToRecord: Compute-Dispatches und kompatible Transferarbeiten, ohne Grafik-Renderpässe.
@@ -42,17 +42,15 @@ concepts.execution.recording.guidance: 'Die Aufzeichnung legt die Befehlsfolge f
concepts.execution.recording.title: 'Aufzeichnung und Einreichung'
concepts.execution.title: Ausführungsmodell
concepts.platforms.description: 'Die Präsentation übernimmt entweder die Anwendung oder ein UI-Steuerelement. Damit steht fest, wer die Ausgabetextur des Frames abruft, Befehle aufzeichnet und einreicht und das Ergebnis präsentiert. Diese Ausgabetextur heißt Drawable.'
-concepts.platforms.frame.context: 'Zeichnen Sie Pipeline-Bindungen und Zeichenbefehle innerhalb des Passes auf und beenden Sie ihn, bevor der Handler zurückkehrt. Das Steuerelement reicht die Befehle ein und präsentiert das Ergebnis. Der Handler darf weder den Befehlspuffer einreichen noch eines der beiden bereitgestellten Objekte freigeben. Ändert er das Texturlayout, muss er vor seiner Rückkehr {colorAttachment} wiederherstellen, damit das Steuerelement den abschließenden Übergang ausführen kann.'
+concepts.platforms.frame.context: 'Zeichnen Sie Pipeline-Bindungen und Zeichenbefehle innerhalb des Passes auf und beenden Sie ihn, bevor der Handler zurückkehrt. Der Handler darf weder den Befehlspuffer einreichen noch eines der beiden bereitgestellten Objekte freigeben. Ändert er das Texturlayout, muss er vor seiner Rückkehr {colorAttachment} wiederherstellen, damit das Steuerelement den abschließenden Übergang ausführen kann.'
concepts.platforms.frame.description: 'Die Steuerelemente implementieren {iZenithView}. Die Anwendung weist {graphicsContext} zu, aktualisiert die Szene in {updateRequested} und zeichnet in {renderRequested} anhand der übergebenen {renderEventArgs} auf.'
concepts.platforms.frame.details: 'Für jeden Frame bezieht das Steuerelement eine Ausgabetextur und einen Befehlspuffer, überführt die Textur nach {colorAttachment} und ruft die Update- und Render-Handler auf. Anschließend reicht es die aufgezeichneten Befehle ein und zeigt das Bild über den Präsentationsmechanismus des Frameworks an.'
concepts.platforms.frame.guidance: 'Ergänzen Sie {usingZenithNET} in der Datei. Für ein initialisiertes {iZenithView} namens {view} mit zugewiesenem Grafikkontext registrieren Sie diesen Handler, der die Ausgabetextur mit einer Farbe füllt:'
concepts.platforms.frame.notes: 'Der anfängliche Übergang verwendet {undefined} und erlaubt damit, den bisherigen Bildinhalt zu verwerfen. Füllen oder zeichnen Sie deshalb in jedem Frame das gesamte Bild neu. Speichern Sie akkumulierte oder zwischengespeicherte Ergebnisse in einer anwendungseigenen Textur und zeichnen Sie diese anschließend in die Ausgabetextur des Steuerelements.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} liefert das Standardfarbformat dieser Integrationen.'
concepts.platforms.frame.title: 'Rendering über UI-Steuerelemente'
concepts.platforms.integration.context: 'WinForms, WPF und die Windows-Integration von WinUI laufen unter Windows. Installieren Sie für MAUI die Workload der Zielplattform und registrieren Sie den Steuerelement-Handler mit {useZenithView}, wie in {extensionsCs} gezeigt.'
concepts.platforms.integration.description: 'Die Ereignisschnittstelle ist gemeinsam, der Präsentationsmechanismus hängt jedoch vom Framework ab:'
-concepts.platforms.integration.details: 'Die Implementierungen unterscheiden sich darin, wie das GPU-Bild in die Oberfläche gelangt. Beim Bitmap-Rücklesen werden die Pixel vor der Anzeige in CPU-Speicher kopiert. Interop über gemeinsam genutzte Texturen vermeidet diese CPU-Kopie, kann aber weiterhin GPU-Kopien und Synchronisation erfordern. Berücksichtigen Sie bei der Wahl der Integration neben dem gemeinsamen Ereignis {renderRequested} auch diesen Präsentationsweg.'
-concepts.platforms.integration.guidance: 'Fügen Sie das Integrationspaket für Ihr UI-Framework über NuGet hinzu. Für Avalonia verwenden Sie {avaloniaPackage}.'
+concepts.platforms.integration.details: 'UI-Integrationen bringen GPU-Bilder auf unterschiedliche Weise in die Benutzeroberfläche. Beim Bitmap-Rücklesen werden Pixel vor der Anzeige in CPU-Speicher kopiert. Interop über gemeinsam genutzte Texturen vermeidet diese Kopie, kann aber weiterhin GPU-Kopien und Synchronisation erfordern. Berücksichtigen Sie bei der Wahl einer Integration neben dem gemeinsamen Ereignis {renderRequested} auch den Präsentationsweg.'
concepts.platforms.integration.table.avalonia.integration: Avalonia
concepts.platforms.integration.table.avalonia.presentation: 'Rendert in eine Textur und liest die Pixel in {writeableBitmap} zurück. Implementierung: {zenithViewCs} und {surfaceCs}.'
concepts.platforms.integration.table.headings.integration: Integration
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: 'Präsentationsmecha
concepts.platforms.integration.table.maui.integration: .NET MAUI
concepts.platforms.integration.table.maui.presentation: 'Verwendet native Oberflächen unter Android, iOS und Mac Catalyst sowie Komposition über gemeinsam genutzte Texturen unter Windows. Siehe die {link}.'
concepts.platforms.integration.table.maui.presentation.link: Plattformimplementierungen
-concepts.platforms.integration.table.uno.integration: Uno-Pfad
+concepts.platforms.integration.table.uno.integration: Uno Platform
concepts.platforms.integration.table.uno.presentation: 'Liest Pixel in {writeableBitmap} zurück. Implementierung: {zenithViewUnoCs}.'
concepts.platforms.integration.table.winForms.integration: WinForms
concepts.platforms.integration.table.winForms.presentation: 'Erstellt eine Zenith.NET-Swapchain für das Fensterhandle {hWND} des Steuerelements. Implementierung: {zenithViewCs}.'
@@ -70,22 +68,22 @@ concepts.platforms.integration.table.wpf.integration: WPF
concepts.platforms.integration.table.wpf.presentation: 'Importiert eine gemeinsam genutzte Direct3D 11-Textur und kopiert ihren Inhalt über Direct3D-Interop in eine von {d3DImage} angezeigte Oberfläche. Siehe {surfaceCs}.'
concepts.platforms.integration.title: 'Framework und Präsentationspfad'
concepts.platforms.lifecycle.context: 'Verwenden Sie {descWidth}, {descHeight}, {descFormat} und {descSampleCount} der im Render-Ereignis bereitgestellten Ausgabetextur, um passende Attachments zu erstellen. Diese Textur liefert die tatsächlichen Maße des Renderziels. Richten Sie sich nach diesen Maßen, statt sie aus der Layoutgröße des Steuerelements oder der Anzeigeskalierung zu berechnen.'
-concepts.platforms.lifecycle.description: 'Die Swapchain verwendet Breite und Höhe des Framebuffers in Pixeln. Bei Anzeigeskalierung können sie von den logischen Fenstermaßen abweichen. Verschieben Sie Rendering und Swapchain-Größenanpassung, solange eine Abmessung null ist. Beziehen Sie {swapChainDrawable} für jeden Frame neu: Diese Textur gehört der Swapchain und kann nach Präsentation oder Größenänderung ersetzt werden.'
+concepts.platforms.lifecycle.description: 'Die Swapchain verwendet Breite und Höhe des Framebuffers in Pixeln. Bei Anzeigeskalierung können sie von den logischen Fenstermaßen abweichen. Setzen Sie Rendering und die Größenanpassung der Swapchain aus, solange eine Abmessung null ist. Beziehen Sie {swapChainDrawable} für jeden Frame neu: Diese Textur gehört der Swapchain und kann nach Präsentation oder Größenänderung ersetzt werden.'
concepts.platforms.lifecycle.details: 'Ändern sich die Framebuffer-Maße, warten Sie vor {swapChainResize} auf alle noch laufenden GPU-Zugriffe auf die alten Bilder. Soll das native Präsentationsziel ersetzt werden, übergeben Sie nach Abschluss dieser Zugriffe seine neue Beschreibung und Handles an {swapChainRefresh}. Geben Sie beim Beenden die Swapchain vor ihrem nativen Präsentationsziel frei.'
concepts.platforms.lifecycle.guidance: 'Richten sich anwendungseigene Tiefen- oder Offscreen-Texturen nach der Fenstergröße, erstellen Sie sie bei einer Größenänderung neu und aktualisieren Sie Konstanten mit ihren Handles. Die Pipeline bleibt verwendbar, solange Attachment-Formate und Sample-Anzahlen weiterhin übereinstimmen. Der {link} zeigt, wie angepasste Texturen und eine wiederverwendete Pipeline zusammenarbeiten.'
concepts.platforms.lifecycle.guidance.link: Renderer des rotierenden Würfels
concepts.platforms.lifecycle.title: 'Swapchain-Abmessungen und Lebensdauer'
concepts.platforms.ownership.description: 'Die Anwendung besitzt den zugewiesenen Kontext und ihre Rendering-Ressourcen, das Steuerelement seine Präsentationsressourcen. Ändert sich {graphicsContext} der Ansicht, erstellt der Scheduler die Steuerelement-Ressourcen für den neuen Kontext neu. Auch die Anwendung muss ihre Pipelines, Puffer und Texturen für diesen Kontext neu erstellen.'
-concepts.platforms.ownership.details: 'Halten Sie vor dem Ersetzen von Rendering-Ressourcen die Frame-Verarbeitung der Ansicht an und warten Sie auf die GPU-Arbeit, die diese Ressourcen verwendet. Erst danach dürfen die alten Ressourcen oder der Kontext freigegeben werden. Auch beim Entfernen der Ansicht bleibt die Anwendung für die Freigabe des zugewiesenen Kontexts verantwortlich.'
+concepts.platforms.ownership.details: 'Halten Sie vor dem Ersetzen von Rendering-Ressourcen die Frame-Schleife der Ansicht an und warten Sie auf die GPU-Arbeit, die diese Ressourcen verwendet. Geben Sie danach die alten Ressourcen frei. Der Kontext darf erst freigegeben werden, wenn jede Ansicht ihre Präsentationsressourcen für diesen Kontext freigegeben hat und alle daraus erstellten Anwendungsressourcen freigegeben wurden.'
concepts.platforms.ownership.guidance: 'Der gemeinsame {frameSchedulerCs} führt die Frame-Handler über den UI-Dispatcher der Ansicht aus. Beschränken Sie diese Handler auf Szenenaktualisierung und Befehlsaufzeichnung; aufwendige CPU-Arbeit verzögert dort auch die Benutzeroberfläche.'
concepts.platforms.ownership.title: 'Verantwortung von Anwendung und Steuerelement'
concepts.platforms.surface.description: 'Das {link} verwendet Silk.NET für Fenstererstellung und Ereignisverarbeitung. Zenith.NET erhält die nativen Fensterhandles und Abmessungen in einer {surface}-Beschreibung und erstellt damit eine {swapChain}. Für das Betriebssystemfenster bleibt die Anwendung verantwortlich.'
concepts.platforms.surface.description.link: 'Dreieck-Tutorial'
-concepts.platforms.surface.details: 'Die nativen Handles müssen zum Backend passen:'
+concepts.platforms.surface.details: 'Die benötigten Oberflächenhandles hängen von der Grafik-API und dem Fenstersystem ab. Häufige Kombinationen sind:'
concepts.platforms.surface.guidance: 'Der Beispielhost in {appCs} unterstützt Windows, macOS und X11. Unter Linux liefert sein Fenster Xlib-Handles; eine Wayland-Sitzung benötigt deshalb XWayland. Eine native Wayland-Anwendung übergibt Display- und Surface-Handles über {surfaceWayland}.'
concepts.platforms.surface.table.android.backend: Vulkan unter Android.
concepts.platforms.surface.table.apple.backend: Metal auf Apple-Plattformen.
-concepts.platforms.surface.table.headings.backend: 'Backend und Plattform'
+concepts.platforms.surface.table.headings.backend: 'Grafik-API und Plattform'
concepts.platforms.surface.table.headings.factory: Oberflächen-Factory
concepts.platforms.surface.table.headings.handles: Vom Host bereitgestellte Handles
concepts.platforms.surface.table.wayland.backend: Vulkan mit einem nativen Wayland-Host.
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'Native Präsentationsziele'
concepts.platforms.title: Plattformintegration
concepts.resources.allocation.context: 'Platzierte Ressourcen benötigen den Speicher ihres Heaps während ihrer gesamten Lebensdauer. Warten Sie auf ihre letzte GPU-Nutzung und geben Sie anschließend zuerst die Ressourcen und dann den Heap frei.'
concepts.resources.allocation.description: 'Verwenden Sie einen {heap}, wenn die Anwendung die Speicherzuteilung selbst verwalten soll. Ressourcen werden darin an expliziten Byte-Offsets platziert. Die Anwendung legt diese Offsets fest und verfolgt die belegten Bereiche.'
-concepts.resources.allocation.details: 'Rufen Sie für jede Ressource {contextGetSizeAndAlignment} mit der Puffer- oder Texturbeschreibung auf, die auch für die Erstellung verwendet wird. Reservieren Sie die zurückgegebene Größe an einem Offset, der ein Vielfaches der angegebenen Ausrichtung ist. Die Allokation muss innerhalb des Heaps liegen und darf keine andere noch aktive Allokation überlappen. Texturgrößen können backendabhängige Auffüllungen enthalten und lassen sich deshalb nicht allein aus Pixelzahl und Bytes pro Pixel berechnen.'
+concepts.resources.allocation.details: 'Rufen Sie für jede Ressource {contextGetSizeAndAlignment} mit der Puffer- oder Texturbeschreibung auf, die auch für die Erstellung verwendet wird. Reservieren Sie die zurückgegebene Größe an einem Offset, der ein Vielfaches der angegebenen Ausrichtung ist. Die Allokation muss innerhalb des Heaps liegen und darf keine andere noch aktive Allokation überlappen. Texturen können Auffüllung benötigen; ihre Allokationsgröße lässt sich deshalb nicht allein aus Pixelzahl und Bytes pro Pixel berechnen.'
concepts.resources.allocation.guidance: 'Ein in einem Heap platzierter Puffer muss dieselbe Residenz wie der Heap angeben. Verwenden Sie für Texturen einen Heap mit GPU-only-Residenz.'
concepts.resources.allocation.title: 'Heap-Allokation'
concepts.resources.bufferUsages.table.constant.role: Shader-Parameter, die über eine Konstantenpuffer-Bindung gelesen werden.
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: 'Uploads kopieren CPU-Daten in eine GP
concepts.resources.transfers.details: 'Stellen Sie vor diesen Aufrufen die erforderlichen Abhängigkeiten zu Zugriffen auf anderen Warteschlangen her. Eine Warteoperation innerhalb der Methode deckt nur ihren eigenen Transfer ab; sie stellt keine Abhängigkeit zu einer anderen Warteschlange her. Bei direktem Zugriff auf gemappten Speicher muss der Aufrufer selbst auf GPU-Zugriffe warten, die mit dem Transfer in Konflikt stehen.'
concepts.resources.transfers.guidance: 'Mit {commandBufferUpload} oder {commandBufferDownload} lassen sich Transfers zusammen mit anderer GPU-Arbeit aufzeichnen und einreichen. Für den Quellspeicher eines Uploads und den Zielspeicher eines Downloads gelten unterschiedliche Anforderungen an die Lebensdauer:'
concepts.resources.transfers.item: 'Während des Upload-Aufrufs kopiert die Bibliothek die Quelldaten in einen temporären Upload-Speicher, den Staging-Speicher. Die GPU liest später aus diesem Zwischenspeicher. Der Quellzeiger der Anwendung wird deshalb nur bis zur Rückkehr des Aufrufs benötigt.'
-concepts.resources.transfers.notes: 'Bei Texturtransfers bezeichnet der Zeilen-Stride den Byte-Abstand zwischen aufeinanderfolgenden Zeilen der CPU-Daten, der Schicht-Stride den Abstand zwischen Tiefenschichten. Mithilfe dieser Werte kopiert der Transfer Daten zwischen CPU-Speicher und GPU-Textur. Warum GPU-Abschluss und Bereitstellung am Download-Ziel getrennte Schritte sind, erläutert {link}.'
-concepts.resources.transfers.notes.link: Synchronisation
+concepts.resources.transfers.layouts: 'Aufgezeichnete Texturtransfers enthalten keine Layoutübergänge. Uploads benötigen {copyDst}, Downloads {copySrc}. Zeichnen Sie vor der Kopie den Übergang in das jeweilige Layout auf und danach den Übergang in das für die nächste Nutzung benötigte Layout.'
+concepts.resources.transfers.notes: 'Bei Texturtransfers bezeichnet der Zeilen-Stride den Byte-Abstand zwischen aufeinanderfolgenden Zeilen der CPU-Daten, der Schicht-Stride den Abstand zwischen Tiefenschichten. Mithilfe dieser Werte kopiert der Transfer Daten zwischen CPU-Speicher und GPU-Textur.'
concepts.resources.transfers.table.bufferDownload.transfer: 'Kopiert bei {cpuReadOnly} direkt aus dem gemappten Speicher. Andernfalls reicht die Methode den Download bei der Transferwarteschlange ein und wartet auf dessen Abschluss.'
concepts.resources.transfers.table.bufferUpload.transfer: 'Kopiert bei {cpuWriteOnly} direkt in den gemappten Speicher. Andernfalls reicht die Methode den Upload bei der Transferwarteschlange ein und wartet auf dessen Abschluss.'
concepts.resources.transfers.table.headings.method: Methode
concepts.resources.transfers.table.headings.transfer: 'Übertragungsverhalten'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'Reicht die Kopie und ihre Texturübergänge bei der Grafikwarteschlange ein und wartet auf den Abschluss. Die ausgewählte Unterressource bleibt im angeforderten abschließenden Layout.'
-concepts.resources.transfers.title: 'Sofortige und aufgezeichnete Übertragungen'
+concepts.resources.transfers.title: 'Sofortige Transfers und Befehlspuffer-Transfers'
concepts.resources.usages.description: '{bufferUsages} und {textureUsages} sind Flag-Enums für die vorgesehenen Ressourcenrollen. Sie werden {bufferDescUsages} beziehungsweise {textureDescUsages} zugewiesen. Für mehrere Rollen lassen sich die benötigten Member mit {value} kombinieren.'
concepts.resources.usages.title: 'Ressourcennutzungen'
-concepts.resources.views.description: 'Eine {bufferView} beschreibt einen Pufferbereich und die Interpretation seiner Daten. Eine {textureView} wählt einen Unterressourcenbereich sowie einen kompatiblen Texturtyp und ein passendes Format. Beide beziehen sich auf vorhandenen Speicher mit den bei seiner Erstellung angegebenen Nutzungen. Ansichtsbereiche beschreiben den Zugriff, gewährleisten aber keine einheitliche shaderseitige Bereichsprüfung über alle Backends hinweg.'
+concepts.resources.views.description: 'Eine {bufferView} beschreibt einen Pufferbereich und die Interpretation seiner Daten. Eine {textureView} wählt einen Unterressourcenbereich sowie einen kompatiblen Texturtyp und ein passendes Format. Beide beziehen sich auf vorhandenen Speicher mit den bei seiner Erstellung angegebenen Nutzungen. Ansichtsbereiche beschreiben den Zugriff, gewährleisten aber keine einheitliche Bereichsprüfung im Shader.'
concepts.resources.views.details: 'Der eigene Handle einer Ressource stellt ihre Standardansicht bereit. Erstellen Sie eine separate Ansicht, wenn ein anderer Bereich oder eine andere kompatible Interpretation benötigt wird. Ansicht und zugrunde liegende Ressource müssen bis zum Ende ihrer GPU-Nutzung erhalten bleiben; ein Ressourcenhandle hält keines dieser Objekte am Leben. Wird eines ersetzt, aktualisieren Sie alle Konstanten mit dem bisherigen {link}.'
concepts.resources.views.details.link: 'Ressourcenhandle'
concepts.resources.views.title: 'Ansichten und zugrunde liegende Ressourcen'
concepts.shaders.binding.context: 'Im Compute-Beispiel erhält {input} den Wert {inputTextureSampledHandle} und {output} den Wert {outputTextureStorageHandle}. In Slang bestimmt der Typparameter von {descriptorHandle} den Ressourcenzugriff:'
concepts.shaders.binding.description: '{setConstantBuffer} wählt einen vorhandenen Puffer und den Byte-Offset, ab dem die aktuelle Pipeline ihre Konstanten liest. Laden Sie die Parameterdaten in diesen Speicher, bevor der Shader darauf zugreift. Liest frühere GPU-Arbeit noch dieselben Bytes, muss sie vor der Aktualisierung abgeschlossen sein.'
concepts.shaders.binding.details: 'Der Befehlspuffer, die Compute-Pipeline, der mit Daten gefüllte Konstantenpuffer und die Anzahl der Threadgruppen müssen bereits vorliegen. Zeichnen Sie den Dispatch dann in dieser Reihenfolge auf. Wählen Sie zuerst die Pipeline, da die Konstantenpufferbindung für diese Pipeline gilt:'
-concepts.shaders.binding.guidance: 'Hier zeichnet {commandBuffer} einen Dispatch mit {computePipeline} und den Parametern aus {constantBuffer} auf. Der Puffer benötigt die Nutzung {bufferUsagesConstant}; Offset 0 wählt seinen Anfang. Teilen sich mehrere Konstantendatensätze einen Puffer, muss jeder Anfangsoffset zusätzlich die Bindungsausrichtung des Backends erfüllen. Diese Anforderung gilt unabhängig von der Feldanordnung innerhalb des Datensatzes.'
-concepts.shaders.binding.notes: '{resourceHandle} enthält zwei 32-Bit-Felder, deren Interpretation vom Backend abhängt. Die Werte gelten nur innerhalb des Kontexts, in dem die Ressource erstellt wurde.'
+concepts.shaders.binding.guidance: 'Der Konstantenpuffer benötigt die Nutzung {bufferUsagesConstant}. Teilen sich mehrere Konstantendatensätze einen Puffer, muss jeder Anfangsoffset die erforderliche Bindungsausrichtung erfüllen. Diese Anforderung gilt unabhängig von der Feldanordnung innerhalb des Datensatzes.'
+concepts.shaders.binding.notes: '{resourceHandle} enthält zwei 32-Bit-Felder, deren Interpretation von der Implementierung der Grafik-API abhängt. Die Werte gelten nur innerhalb des Kontexts, in dem die Ressource erstellt wurde.'
concepts.shaders.binding.reference: 'Ressource und zugehörige Ansicht müssen bis zum Abschluss des letzten Shader-Zugriffs erhalten bleiben. Ihr Ersatz erfordert eine Aktualisierung der Konstanten mit alten Handles. Die Besitzregeln erläutert {link}.'
concepts.shaders.binding.reference.link: Ressourcenverwaltung
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'Lesen strukturierter Elemente des im Shader verwendeten Datentyps {t}'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: 'Zustand für die Texturabt
concepts.shaders.binding.table.textureSampledHandle.access: 'Lesen von Texturdaten'
concepts.shaders.binding.table.textureStorageHandle.access: 'Lese- und Schreibzugriff auf Speichertexturen'
concepts.shaders.binding.title: 'Konstantenpuffer und Ressourcenhandles'
-concepts.shaders.compilation.description: '{zenithCompiler} kompiliert einen benannten Slang-Einstiegspunkt zu einer {shaderDesc}. Die Eigenschaft {graphicsApi} bestimmt das Ziel: DXIL für DirectX 12, eine Metal-Bibliothek für Metal oder SPIR-V für Vulkan.'
+concepts.shaders.compilation.description: '{zenithCompiler} kompiliert einen Slang-Einstiegspunkt und gibt eine {shaderDesc} zurück. Die Eigenschaft {graphicsApi} des Kontexts bestimmt das Ausgabeformat: {dxil} für DirectX 12, {metallib} für Metal oder {spirv} für Vulkan.'
concepts.shaders.compilation.details: 'Mit einem bereits erstellten Grafikkontext namens {context} wird der Dreieck-Shader aus der Kopie neben der ausführbaren Datei kompiliert:'
concepts.shaders.compilation.guidance: 'Der Einstiegspunktname {vSMain} muss mit der Deklaration in der Shader-Datei übereinstimmen. Kompilieren Sie Shader und erstellen Sie Pipelines während der Initialisierung; beim Rendering werden die Pipelines wiederverwendet. Nach Abschluss der Pipeline-Erstellung dürfen die Shader-Objekte freigegeben werden, wie im Tutorial {link} gezeigt.'
concepts.shaders.compilation.guidance.link: Erstes Dreieck
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: 'Für Vertexeingaben beschreibt {inputLayou
concepts.shaders.layout.details: 'Konstantenpuffer enthalten Shader-Parameter, strukturierte Puffer Arrays typisierter Elemente. Ihre Anordnung folgt den Slang-Deklarationen und nicht {inputLayout}. Stimmen Sie C#-Feldoffsets, Elementgrößen und Auffüllungen mit dem kompilierten Shader-Layout ab. Ein nicht verwalteter C#-Typ lässt sich als Bytes kopieren, doch seine Speicheranordnung entspricht nicht zwangsläufig dem Shader-Layout. Ein im Vertex dicht gepacktes {float3} kann in einem Shader-Puffer eine andere Ausrichtung benötigen.'
concepts.shaders.layout.guidance: 'Shader-Parameter können neben gewöhnlichen Werten auch Ressourcenhandles enthalten. Ein Handle bezeichnet bereits vorhandenen Speicher. Wird er in einen Konstantenpuffer kopiert, werden deshalb nicht die Inhalte der Ressource mitkopiert.'
concepts.shaders.layout.notes: 'Die zugehörige Deklaration in {computeShaderSlang} lautet:'
-concepts.shaders.layout.reference: 'Die beiden Abmessungen belegen die ersten acht Bytes; darauf folgen zwei Handles mit je acht Bytes. Das C#-Beispiel reserviert insgesamt 256 Bytes für den Datensatz. Die Größe anderer Datensätze ist anhand ihrer eigenen Felder sowie der benötigten Anordnung und Ausrichtung zu bestimmen.'
+concepts.shaders.layout.reference: 'Die C#-Felder belegen die ersten 24 Bytes: acht für die Abmessungen und je acht für die beiden Handles. Im 256-Byte-Datensatz bleiben die übrigen Bytes als Auffüllung frei. Stimmen Sie bei einem anderen Parameterblock die Feldoffsets auf dessen Shader-Layout ab. Teilen sich mehrere Datensätze einen Puffer, muss die Auffüllung zwischen ihnen für die erforderliche Bindungsausrichtung ausreichen.'
concepts.shaders.layout.title: 'Datenlayout'
concepts.shaders.matrices.description: 'Der Compiler wählt zeilenweise Matrixspeicherung mit zusammenhängenden Zeilen. Der {link} speichert drei {matrix4x4}-Werte an den Byte-Offsets 0, 64 und 128. Sein {detail} führt {mulVectorMatrix} in Modell-, View- und Projektionsreihenfolge aus.'
concepts.shaders.matrices.description.detail: Shader
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: Renderer des rotierenden Würfels
concepts.shaders.matrices.details: 'Die Speicherreihenfolge bestimmt die Anordnung der Matrixelemente; die Multiplikationsreihenfolge bestimmt die Transformation. C# und Slang müssen aufeinander abgestimmte Konventionen verwenden.'
concepts.shaders.matrices.title: 'Matrixkonventionen'
concepts.shaders.title: Shader-Daten und Bindung
-concepts.synchronization.backends.description: 'DirectX 12 und Vulkan setzen Texturübergänge als Layout- und Zugriffsänderungen um. Für Metal führt die Implementierung von {transition} in Zenith.NET keine entsprechende Operation aus. Das Metal-Backend fasst Befehle stattdessen in Render- und Compute-Encodern zusammen und fügt beim Ende eines Encoders Sichtbarkeitsbarrieren ein. Abhängige Operationen innerhalb desselben Encoders, etwa aufeinanderfolgende Compute-Dispatches, verwenden explizite Aufrufe von {barrier}.'
-concepts.synchronization.backends.details: 'Im {link} beendet der Beginn des Grafik-Renderpasses den Compute-Encoder und macht dessen Ausgabe für die Grafikbefehle sichtbar. Zwei aufeinanderfolgende Compute-Dispatches bleiben dagegen im selben Encoder. Ihre Abhängigkeit benötigt deshalb eine Barriere, auch wenn dazwischen ein Texturübergang aufgezeichnet wird. Portable Befehlsfolgen berücksichtigen daher sowohl Zugriffsabhängigkeiten als auch Texturlayouts.'
+concepts.synchronization.backends.description: 'DirectX 12 und Vulkan setzen Texturübergänge als Layout- und Zugriffsänderungen um. In der Metal-Implementierung von Zenith.NET löst {transition} keine entsprechende GPU-Operation aus. Diese Implementierung fasst Befehle in Render- und Compute-Encodern zusammen und fügt beim Ende eines Encoders Sichtbarkeitsbarrieren ein. Abhängige Operationen innerhalb desselben Encoders, etwa aufeinanderfolgende Compute-Dispatches, erfordern explizite Aufrufe von {barrier}.'
+concepts.synchronization.backends.details: 'Im {link} beendet der Beginn des Grafik-Renderpasses den Compute-Encoder und macht dessen Ausgabe für die Grafikbefehle sichtbar. Zwei aufeinanderfolgende Compute-Dispatches bleiben dagegen im selben Encoder. Ihre Abhängigkeit benötigt deshalb eine Barriere, auch wenn dazwischen ein Texturübergang aufgezeichnet wird.'
concepts.synchronization.backends.details.link: Compute-Beispiel
-concepts.synchronization.backends.title: 'Backend-Verhalten'
+concepts.synchronization.backends.title: 'Synchronisierung je nach Grafik-API'
concepts.synchronization.barriers.context: 'Wählen Sie Stufen, die die relevanten Zugriffe umfassen und von der Warteschlange unterstützt werden. {barrierStagesAll} schließt alle unterstützten Stufen ein. Beschränken Sie die Auswahl, wenn die Abhängigkeit nur einen Teil davon betrifft.'
concepts.synchronization.barriers.description: 'Angenommen, zwei Compute-Dispatches stehen im selben Befehlspuffer: Der erste schreibt Simulationsdaten, der zweite liest sie. Eine Barriere dazwischen stellt sicher, dass der zweite Dispatch die abgeschlossenen Schreibvorgänge sieht. Bei einem Speicherpuffer genügt es, die Zugriffe zu ordnen; ein Texturlayoutübergang ist nicht erforderlich:'
concepts.synchronization.barriers.details: 'Das erste Argument benennt die Stufen, die die Daten erzeugt haben; das zweite die Stufen, die sie verwenden werden. Gemeinsam beschreiben sie die benötigte Ausführungsreihenfolge und Speichersichtbarkeit zwischen den beiden Dispatches.'
-concepts.synchronization.barriers.guidance: 'Die {link} verwendet dieses Muster zwischen Simulationsschritten. Jede Barriere steht nach dem Dispatch, der die Daten erzeugt, und vor dem Dispatch, der sie verwendet.'
+concepts.synchronization.barriers.guidance: 'Die {link} verwendet dieses Muster zwischen Simulationsschritten.'
concepts.synchronization.barriers.guidance.link: FluidTank-Simulation
concepts.synchronization.barriers.title: 'Pipeline-Barrieren'
concepts.synchronization.dependencies.description: 'Ermitteln Sie für jede Ressource, welche Zugriffe dieselben Daten betreffen. Sobald einer davon schreibt, muss die benötigte Reihenfolge erhalten bleiben. Zwei Lesezugriffe stehen nicht im Konflikt; Anforderungen an Texturlayout und Präsentation gelten dennoch. Auch CPU-Aktualisierungen und Ressourcenfreigaben müssen warten, bis die GPU den betroffenen Speicher nicht mehr verwendet.'
concepts.synchronization.dependencies.details: 'Der Mechanismus richtet sich nach dem Ausführungsort der Operationen:'
-concepts.synchronization.dependencies.guidance: 'Eine Aufgabe kann mehrere Mechanismen benötigen. Stammt eine Textur etwa aus einer anderen Warteschlange, sind sowohl eine Einreichungsabhängigkeit als auch das passende Layout für den nächsten Zugriff erforderlich. Die CPU muss dafür nur blockiert werden, wenn sie selbst auf die Daten zugreifen oder deren Speicher freigeben soll.'
+concepts.synchronization.dependencies.guidance: 'Schreibt eine Warteschlange in eine Textur, die eine andere verwendet, reichen Sie die Arbeit mit einer Abhängigkeit ein und zeichnen Sie den benötigten Layoutübergang auf. Keiner dieser Schritte blockiert die CPU. Warten Sie auf den Abschluss, bevor die CPU auf die Daten zugreift oder die Ressource freigibt.'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: '{wait} auf dem relevanten Abschlusswert aufrufen.'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'CPU-Zugriff oder Ressourcenfreigabe erfordert den Abschluss der GPU-Arbeit'
concepts.synchronization.dependencies.table.crossQueue.mechanism: 'Den {timelineValue} der erzeugenden Einreichung an {submit} der weiterverarbeitenden Einreichung übergeben.'
@@ -256,7 +254,7 @@ home.entries.reference.category: Referenz
home.entries.reference.description: 'API-Typen, Member und Deklarationen nachschlagen'
home.entries.reference.title: API-Referenz
home.entries.samples.action: Beispiele durchsuchen
-home.entries.samples.category: Beispiele
+home.entries.samples.category: Codebeispiele
home.entries.samples.description: 'Ausführbare Beispiele für Grafik- und Compute-Verfahren'
home.entries.samples.title: Beispiele
home.entries.title: 'Dokumentation'
@@ -264,11 +262,11 @@ home.entries.tutorial.action: Tutorial starten
home.entries.tutorial.category: Tutorial
home.entries.tutorial.description: 'Vom leeren Projekt zum ersten Dreieck auf dem Bildschirm'
home.entries.tutorial.title: Erstes Dreieck
-home.introduction.accent: 'auf mehreren Plattformen'
-home.introduction.description: 'Zenith.NET bündelt Grafik und Compute für DirectX, Metal und Vulkan in einer gemeinsamen API'
-home.introduction.title: 'Grafik für .NET{lineBreak}{accent}'
-home.meta.description: 'Plattformübergreifende Grafik und Compute für .NET mit einer gemeinsamen API für DirectX, Metal und Vulkan'
-home.scene.description: 'Interaktive rotierende Geometrie. Ansicht durch Ziehen oder mit den Pfeiltasten verändern.'
+home.introduction.accent: 'für .NET'
+home.introduction.description: 'Zenith.NET bündelt Grafik und Compute für DirectX 12, Metal 4 und Vulkan 1.4 in einer gemeinsamen API'
+home.introduction.title: 'Plattformübergreifende Grafik{lineBreak}{accent}'
+home.meta.description: 'Plattformübergreifende Grafik und Compute für .NET mit einer gemeinsamen API für DirectX 12, Metal 4 und Vulkan 1.4'
+home.scene.description: 'Interaktive rotierende Geometrie. Ziehen Sie die Geometrie oder verwenden Sie die Pfeiltasten, um die Ansicht zu ändern.'
home.scene.label: Geometrieanzeige
home.scene.surface: Oberfläche
home.scene.wireframe: Drahtgitter
@@ -280,7 +278,7 @@ learning.concepts.resources.description: 'Ressourcennutzungen, Speicherplatzieru
learning.concepts.shaders.description: 'Layout- und Bindungskonventionen für C# und Slang'
learning.concepts.synchronization.description: 'Abhängigkeiten, Sichtbarkeit und Abschluss'
learning.concepts.title: Kernkonzepte
-learning.description: 'Beginnen Sie mit dem Dreieck-Tutorial und erstellen Sie Ihre erste Anwendung. Anschließend erläutern die Konzeptartikel Ressourcenverwaltung, Shader-Daten und Synchronisation. Für einzelne Grafikverfahren stehen ausführbare Beispiele bereit.'
+learning.description: 'Beginnen Sie mit dem Dreieck-Tutorial und erstellen Sie Ihre erste Anwendung. Lesen Sie danach die Konzeptartikel über Ressourcenverwaltung, Shader-Daten und Synchronisation oder wählen Sie ein Beispiel für das Verfahren, das Sie umsetzen möchten.'
learning.entries.samples.action: Beispiele durchsuchen
learning.entries.samples.description: 'C#- und Slang-Implementierungen für Geometrie, Compute, Ray-Queries und Mesh-Shading'
learning.entries.tutorial.action: Tutorial öffnen
@@ -290,71 +288,65 @@ learning.title: Lernen
reference.description: 'Referenz zu Ressourcen, Befehlen und Plattformintegration'
reference.entries.commands.description: 'Grafik-, Compute- und Transferbefehle'
reference.entries.commands.label: 'Befehle aufzeichnen'
-reference.entries.context.description: 'GPU-Ressourcenerstellung für das gewählte Backend'
+reference.entries.context.description: 'Erstellung von GPU-Ressourcen über einen Grafikkontext'
reference.entries.context.label: Hier beginnen
reference.meta.description: 'Namespaces, Typen und Member von Zenith.NET'
reference.navigation.core: 'Referenz der Kern-API'
reference.title: API-Referenz
-samples.computeShader.description: 'Das Beispiel lädt {assetsTexturesShokoPng}, wandelt das Bild mit einem Compute-Dispatch in Graustufen um und zeigt die Ausgabetextur an. Die Umwandlung erfolgt einmal; spätere Frames zeigen dasselbe Ergebnis. Der Renderer zeigt die Bindung abtastbarer und beschreibbarer Texturen, das Aufrunden der Threadgruppenanzahl zur vollständigen Bildabdeckung und die Bereichsprüfung im Shader.'
+samples.computeShader.description: 'Ein Compute-Shader wandelt ein Farbbild in Graustufen um und demonstriert damit Bildverarbeitung auf der GPU.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: Compute-Shader
-samples.cube.description: 'Der Würfel ergänzt indexiertes Zeichnen, Modell-, View- und Projektionsmatrizen in einem Konstantenpuffer sowie Tiefentests. Seine Tiefen-/Stencil-Textur im Format {d32FloatS8UInt} wird bei Größenänderungen neu erstellt.'
+samples.cube.description: 'Ein rotierender Würfel führt in indexierte Geometrie, 3D-Transformationen und Tiefentests ein.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: Rotierender Würfel
-samples.description: 'Jedes Beispiel verbindet einen C#-Renderer mit seinem Slang-Shader und behandelt ein bestimmtes Verfahren. Den vollständigen Anwendungsaufbau und die Rendersequenz erläutert {link}.'
-samples.description.link: Erstes Dreieck
+samples.description: 'Die Beispiele zeigen Grafik- und Compute-Verfahren vom einzelnen Dreieck bis hin zu interaktiven Anwendungen und Diagnosewerkzeugen.'
samples.execution.description: 'Starten Sie das Projekt {link} und wählen Sie ein Beispiel im Konsolenmenü.'
samples.execution.description.link: ZenithTutorials
samples.execution.title: 'Beispiele ausführen'
-samples.host.description: '{appCs} initialisiert Kontext, Fenster und Swapchain. Pro Frame bezieht der Host einen Befehlspuffer, ruft den Renderer auf, reicht die Befehle ein und präsentiert das Ergebnis. {iRendererCs} definiert Aktualisierung, Rendering, Größenanpassung und Freigabe.'
-samples.host.details: 'Die Compute- und Raytracing-Renderer erzeugen Offscreen-Texturen. {texturePresenterCs} und {presentTextureSlang} zeichnen diese in die aktuelle Ausgabetextur. Anschließend reicht der gemeinsame Host die Befehle ein und präsentiert den Frame.'
-samples.host.title: 'Host und Präsentation'
-samples.indirectDrawing.description: 'Indirektes Zeichnen stellt mehrere Würfelinstanzen aus einem Puffer für indexierte Zeichenargumente und einem strukturierten Puffer mit Instanzdaten dar. Die CPU liefert die Argumente und aktualisiert die Transformationen.'
+samples.indirectDrawing.description: 'Ein Raster aus rotierenden, unterschiedlich gefärbten Würfeln zeigt indirektes Zeichnen mit Zeichenargumenten aus einem Puffer.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: Indirektes Zeichnen
-samples.meshShading.description: 'Ein Task-Shader sortiert nicht sichtbare Kugelinstanzen aus und übergibt die verbleibenden Indizes an den Mesh-Shader, der die Geometrie erzeugt. Vor der Pipeline-Erstellung prüft der Renderer {contextCapabilitiesMeshShadingSupported}.'
+samples.meshShading.description: 'Dieses Beispiel verwendet Task- und Mesh-Shader, um ein Raster farbiger Kugeln zu zeichnen und Kugeln außerhalb des Kamerasichtbereichs auszulassen. Erfordert Mesh-Shading-Unterstützung.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: Mesh-Shading
-samples.rayTracing.description: 'Das Beispiel erstellt Beschleunigungsstrukturen der unteren und oberen Ebene für einen Boden und prozedurale Kugeln und führt Inline-Rayqueries in einem Compute-Shader aus. Vor der Initialisierung prüft es {contextCapabilitiesRayTracingSupported}.'
+samples.rayTracing.description: 'Dieses Beispiel verwendet Ray-Queries, um reflektierende Kugeln und Schatten auf einem Schachbrettboden darzustellen. Erfordert Raytracing-Unterstützung.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: Raytracing
samples.title: Beispiele
-samples.triangle.description: 'Das Dreieck verbindet einen Vertexpuffer mit dem passenden Eingabelayout und zeichnet drei Vertices durch eine Grafikpipeline.'
+samples.triangle.description: 'Ein Dreieck mit fließenden Übergängen zwischen den Vertexfarben führt in die grundlegende Grafikpipeline ein.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: Vollständiges Tutorial
samples.triangle.title: Hallo Dreieck
-samples.workloads.description: 'Das {link} im Haupt-Repository enthält größere Anwendungen, die den Bibliotheksquellcode referenzieren.'
+samples.workloads.description: 'Das {link} im Zenith.NET-Repository enthält diese Anwendungen und Hilfsprogramme.'
samples.workloads.description.link: Verzeichnis Experiments
-samples.workloads.details: 'Die Fensterexperimente nutzen dieselben Präsentationspfade für Windows, macOS und Linux/X11. UI-Steuerelemente für Avalonia, WinForms, WPF, WinUI/Uno und MAUI behandelt {link}, einschließlich Frame-Ablauf und Implementierungsquellen.'
-samples.workloads.details.link: Plattformintegration
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: CornellBox
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Pathtracing, Rauschunterdrückung, Tone-Mapping, Hochskalierung und ImGui-Steuerelemente. Erfordert Raytracing-Unterstützung.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Eine interaktive Raumszene zum Erkunden von Beleuchtung und Reflexionen. Erfordert Raytracing-Unterstützung.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: FluidTank
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Compute-Fluidsimulation, Abhängigkeiten zwischen Simulationsstufen und mehrpassiges Oberflächen-Rendering.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Eine Wassersimulation in einem Becken mit einer Oberflächen- und einer Partikelansicht.'
samples.workloads.table.headings.example: Beispiel
-samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Verfahren und Voraussetzungen'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Beschreibung'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: InkCanvas
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Skia-Zeichnen und Eingabeverarbeitung in einem nativen Fenster. Erfordert das Backend und die native Skia-Bibliothek für die Zielplattform.
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Eine Zeichenfläche, auf der sich Freihandstriche zeichnen und wieder löschen lassen.
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: PlatformDetection
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Versucht für jedes Backend einen Kontext zu erstellen und meldet die Gerätefunktionen. Ein fehlgeschlagener Versuch wird als nicht unterstützt gemeldet; Ursache können das Gerät, der Treiber oder eine fehlende Laufzeitabhängigkeit sein.'
-samples.workloads.title: 'Umfangreichere Anwendungen'
-tutorial.context.description: 'Ein {graphicsContext} verbindet die Anwendung über ein Backend mit der GPU und stellt die Methoden zum Erstellen der Rendering-Ressourcen bereit.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Ein Konsolenprogramm, das die verfügbaren Grafik-APIs und die Gerätefunktionen anzeigt.'
+samples.workloads.title: 'Anwendungen und Hilfsprogramme'
+tutorial.context.description: 'Ein {graphicsContext} verbindet die Anwendung über die gewählte Grafik-API mit der GPU und stellt Methoden zur Erstellung von Rendering-Ressourcen bereit.'
tutorial.context.details: 'Fügen Sie die Kontextinitialisierung {emphasis} ein:'
tutorial.context.details.emphasis: nach den using-Direktiven, vor {iWindowWindow}
-tutorial.context.guidance: 'Jeder Zweig wählt das Backend der aktuellen Plattform und fordert Validierung an. Meldungen von {validationMessage} werden in der Konsole ausgegeben.'
+tutorial.context.guidance: 'Jeder Zweig fordert für seine Grafik-API die Validierung an. Der Handler gibt Diagnosen von {validationMessage} aus, sofern die Implementierung solche Meldungen bereitstellt.'
tutorial.context.imports: 'Ergänzen Sie am Anfang von {programCs} die folgenden using-Direktiven:'
tutorial.context.title: 'Grafikkontext'
tutorial.description: 'In diesem Tutorial entsteht aus einem leeren .NET-Konsolenprojekt eine Anwendung, die ein Fenster öffnet und ein farbiges Dreieck zeichnet.'
tutorial.details: 'Das Tutorial führt über drei überprüfbare Zwischenstände zum Ergebnis: ein leeres Fenster, eine einfarbige Fläche und schließlich das farbige Dreieck. Führen Sie die Anwendung nach jedem dieser Schritte aus, bevor Sie den nächsten Teil ergänzen.'
tutorial.draw.context: 'Die Argumente für {draw} sind:'
tutorial.draw.description: 'Ersetzen Sie im Callback {windowRender} den Kommentar {addTheTriangleDrawCommandsHereLater} durch folgende Befehle zwischen {beginRenderPass} und {endRenderPass}:'
-tutorial.draw.details: '{setPipeline} wählt Shader und Renderzustand. Der Aufruf muss vor der Vertexbindung stehen, weil deren Interpretation vom Eingabelayout der Pipeline abhängt.'
+tutorial.draw.details: '{setPipeline} wählt Shader und Renderzustand aus. Binden Sie die Pipeline vor dem Vertexpuffer, damit ihr Eingabelayout bestimmt, wie die Vertexdaten gelesen werden.'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} bindet die hochgeladenen Vertexdaten ab Byte-Offset 0 an Eingabeslot 0. Dieser entspricht dem einzigen Eintrag in {inputLayouts}.'
-tutorial.draw.notes: 'Diese Aufrufe zeichnen die Zeichenbefehle auf. Das vorhandene {submitWait} reicht sie ein und wartet auf ihren GPU-Abschluss; {present} fordert anschließend die Anzeige des fertigen Bildes an. Behalten Sie das Füllen mit der Hintergrundfarbe am Anfang des Passes bei, damit auch die Fläche außerhalb des Dreiecks einen definierten Inhalt hat.'
+tutorial.draw.notes: 'Behalten Sie das Füllen mit der Hintergrundfarbe am Anfang des Passes bei, damit die Fläche außerhalb des Dreiecks eine definierte Hintergrundfarbe hat.'
tutorial.draw.table.firstInstance.meaning: Instanznummerierung bei null beginnen.
tutorial.draw.table.firstVertex.meaning: 'Mit dem ersten Vertex im Puffer beginnen.'
tutorial.draw.table.headings.argument: Argument
@@ -370,25 +362,25 @@ tutorial.execution.title: 'Anwendung ausführen'
tutorial.frame.commands.context: 'Nach {endRenderPass} bereitet der zweite Übergang die Präsentation vor. {submit} beendet die Aufzeichnung und reicht den Befehlspuffer ein; {wait} blockiert bis zu dessen Abschluss. Danach fordert {present} die Bildanzeige an.'
tutorial.frame.commands.description: 'Ein Renderpass fasst Zeichenoperationen zusammen, die in dieselben Attachments schreiben. Hier nimmt die Ausgabetextur der Swapchain die Farbausgabe auf. {colorAttachmentClear} legt fest, dass dieses Attachment zu Beginn mit einer RGBA-Farbe gefüllt und sein Inhalt am Ende erhalten wird. {beginRenderPass} zeichnet den Beginn des Passes mit diesen Einstellungen auf.'
tutorial.frame.commands.details: 'Die Sammlung enthält ein Farb-Attachment. {null} gibt an, dass der Pass kein Tiefen-/Stencil-Attachment verwendet.'
-tutorial.frame.commands.guidance: '{beginRenderPass} setzt Viewport und Scissor auf die gesamte Attachment-Fläche. Der Viewport bildet Renderkoordinaten auf Pixelpositionen ab; der Scissor begrenzt den Bereich, in den geschrieben werden darf.'
+tutorial.frame.commands.guidance: '{beginRenderPass} setzt Viewport und Scissor auf die gesamte Attachment-Fläche. Der Viewport bildet Renderkoordinaten auf Pixelpositionen ab; der Scissor begrenzt den Pixelbereich, den Zeichenoperationen verändern können.'
tutorial.frame.commands.title: 'Löschen, Einreichung und Präsentation'
-tutorial.frame.description: 'Füllen Sie das Fenster zunächst mit einer Hintergrundfarbe. Diese Operation heißt Löschen. Sobald die Farbe sichtbar ist, arbeiten das native Präsentationsziel, die Befehlseinreichung und die Präsentation zusammen. Darauf bauen die Vertices und Shader des Dreiecks auf.'
-tutorial.frame.details: 'Silk.NET ruft den Render-Callback auf, sobald ein Frame ansteht. Das Zeitargument wird nicht verwendet und erhält den Namen {value}. Registrieren Sie den Callback {emphasis}:'
+tutorial.frame.description: 'Füllen Sie das Fenster zunächst mit einer einheitlichen Farbe. Diese Operation heißt Löschen. Erscheint die Farbe, funktionieren Befehlseinreichung und Präsentation. Danach fügen Sie die Vertices und Shader des Dreiecks hinzu.'
+tutorial.frame.details: 'Silk.NET ruft den Render-Callback auf, sobald ein Frame ansteht. Registrieren Sie den Callback {emphasis}:'
tutorial.frame.details.emphasis: vor {windowRun}
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} liefert einen aufzeichnungsbereiten Befehlspuffer. Die Aufzeichnung beschreibt GPU-Arbeit; ausgeführt wird sie erst nach der Einreichung.'
+tutorial.frame.target.description: 'Eine Befehlswarteschlange nimmt aufgezeichnete Arbeit zur Ausführung auf der GPU entgegen. {graphicsQueueCommandBuffer} liefert einen Befehlspuffer aus der Grafikwarteschlange, in dem die Aufzeichnung bereits läuft. Die aufgezeichneten Befehle legen die GPU-Arbeit fest; ihre Ausführung beginnt erst nach der Einreichung.'
tutorial.frame.target.details: 'Ein Texturlayout beschreibt, welchen Zugriff eine Operation benötigt. Der erste Aufruf von {transition} bereitet die Ausgabetextur als Farb-Attachment vor. {default} wählt Mip-Level 0 und Array-Layer 0, also das Basisbild dieser Textur. Da der Pass das gesamte Bild mit einer Hintergrundfarbe füllt, darf {undefined} den bisherigen Inhalt verwerfen.'
tutorial.frame.target.guidance: 'Verwenden Sie in jedem Frame die aktuelle Ausgabetextur, da die Präsentation zum nächsten Bild wechseln kann.'
tutorial.frame.target.title: Ausgabetextur vorbereiten
tutorial.frame.title: 'Der erste Frame'
tutorial.geometry.data.description: 'Fügen Sie das Vertexarray {emphasis} ein. Auch die anschließende Ressourceninitialisierung steht in der angegebenen Reihenfolge vor diesem Callback.'
tutorial.geometry.data.description.emphasis: vor {windowRender}
-tutorial.geometry.data.details: 'Jeder Eintrag erstellt einen {vertex}; die beiden inneren {new}-Ausdrücke liefern {vector3}-Position und {vector4}-Farbe. Die Positionen bilden die obere, rechte untere und linke untere Ecke. Der Vertex-Shader ergänzt {w} als vierte Koordinate. Bei w = 1 sind x und y zugleich normalisierte Gerätekoordinaten: -1 und +1 markieren die Bildgrenzen, 0 die Mitte, unabhängig von Pixelmaßen.'
+tutorial.geometry.data.details: 'Die drei Positionen bilden die obere, rechte untere und linke untere Ecke. In diesem Beispiel erstrecken sich x und y von -1 bis +1 über das Bild: 0 liegt in der Mitte, positive x-Werte zeigen nach rechts und positive y-Werte nach oben.'
tutorial.geometry.data.guidance: 'Jede Farbe hat Rot-, Grün-, Blau- und Alpha-Komponenten; Alpha ist 1. Alle drei Vertices liegen mit z = 0 in derselben Ebene.'
tutorial.geometry.data.title: 'Vertexpositionen und Farben'
tutorial.geometry.description: 'Jeder der drei Vertices besitzt eine Position und eine Farbe. Aus den Positionen ergibt sich die Form des Dreiecks; die GPU interpoliert die Farben über dessen Fläche.'
tutorial.geometry.format.description: 'Ergänzen Sie die Vertexdeklaration {emphasis}:'
tutorial.geometry.format.description.emphasis: am Ende von {programCs}, nach den Bereinigungsanweisungen
-tutorial.geometry.format.details: '{file} beschränkt den Typ auf {programCs}, und {layoutKindSequential} erhält die Deklarationsreihenfolge seiner Felder. {position} enthält drei 32-Bit-Gleitkommazahlen und beginnt am Byte-Offset 0; {color} enthält vier und beginnt am Byte-Offset 12. Ein Vertex belegt damit 28 Bytes. Das Eingabelayout beschreibt diese Anordnung, damit die GPU die Felder korrekt liest.'
+tutorial.geometry.format.details: '{layoutKindSequential} erhält die Deklarationsreihenfolge der Felder. {position} enthält drei 32-Bit-Gleitkommazahlen und beginnt am Byte-Offset 0; {color} enthält vier und beginnt am Byte-Offset 12. Ein Vertex belegt damit 28 Bytes. Das Eingabelayout beschreibt diese Anordnung, damit die GPU die Felder korrekt liest.'
tutorial.geometry.format.imports: 'Ergänzen Sie am Anfang von {programCs} diese using-Direktiven für die Vektortypen und das Attribut zur Festlegung des Strukturlayouts:'
tutorial.geometry.format.title: 'Vertexdarstellung'
tutorial.geometry.title: 'Vertexdaten'
@@ -397,8 +389,7 @@ tutorial.geometry.upload.description: 'Speichern Sie die Vertices in einem {buff
tutorial.geometry.upload.details: '{sizeofVertexVerticesLength} ergibt drei Vertices zu 28 Bytes, insgesamt 84 Bytes. {bufferUsagesVertex} deklariert Vertex-Eingabezugriff, {cpuWriteOnly} ermöglicht die direkte CPU-Initialisierung. Der Stride beschreibt die Elementgröße; das anschließende Eingabelayout bestimmt die Interpretation jedes Attributs.'
tutorial.geometry.upload.guidance: 'Die Allokation initialisiert den Inhalt nicht. {upload} kopiert das Array ab Ziel-Byte-Offset 0 mit dem Quellzeiger und der Bytezahl der Datenbeschreibung.'
tutorial.geometry.upload.imports: 'Ergänzen Sie {bufferAlias} bei den using-Direktiven in {programCs}, um den Puffertyp von Zenith.NET von {systemBuffer} zu unterscheiden.'
-tutorial.geometry.upload.notes: 'Setzen Sie {vertexBufferDispose} direkt vor {swapChainDispose} in die Bereinigung am Ende von {programCs}. GPU-only-Speicher und Transfer-Uploads für größere Geometrie erläutert {link}.'
-tutorial.geometry.upload.notes.link: Ressourcenverwaltung
+tutorial.geometry.upload.notes: 'Setzen Sie {vertexBufferDispose} direkt vor {swapChainDispose} in die Bereinigung am Ende von {programCs}.'
tutorial.geometry.upload.title: 'Pufferallokation und Upload'
tutorial.input.description: 'Die GPU muss wissen, wo Attribute wie Position und Farbe gespeichert sind. Das Eingabelayout gibt Format und Byte-Offset jedes Attributs sowie den Stride an, also den Byte-Abstand zum nächsten Vertex. Fügen Sie diesen Code nach der Shader-Erstellung ein:'
tutorial.input.details: '{inputLayoutAdd} fügt jedes Attribut unmittelbar nach dem vorherigen ein und erhöht den Stride um die Größe des neu hinzugefügten Attributs. Die Offsets ergeben sich aus den angegebenen Formaten; die C#-Struktur wird dabei nicht untersucht. Für diese beiden Felder entsteht folgendes Layout:'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: Nächster Eingabedatensatz
tutorial.input.table.vertexColor.format: '{float4} (16 Bytes)'
tutorial.input.table.vertexPosition.format: '{float3} (12 Bytes)'
tutorial.input.title: 'Vertex-Eingabelayout'
-tutorial.lifecycle.description: 'Jeder Frame folgt dieser Sequenz:'
-tutorial.lifecycle.details: 'Nach dem Schließen des Fensters kehrt {run} zurück, und die Ausführung wird mit der Bereinigung fortgesetzt. Da jeder Frame bereits auf den Abschluss seiner eingereichten Befehle gewartet hat, können die dafür verwendeten Ressourcen nun freigegeben werden. Nach {windowRun} steht die vollständige Bereinigung:'
+tutorial.lifecycle.description: 'In jedem Frame bezieht die Anwendung die aktuelle Ausgabetextur, überführt sie für das Rendering, löscht sie und zeichnet das Dreieck. Anschließend überführt sie die Textur für die Präsentation, reicht die Befehle ein, wartet auf den Abschluss und präsentiert das Bild.'
+tutorial.lifecycle.details: 'Nach dem Schließen des Fensters kehrt {run} zurück, und die Ausführung wird mit der Bereinigung fortgesetzt. Da der Render-Callback bereits auf den Abschluss der Befehle jedes Frames gewartet hat, können die dafür verwendeten Ressourcen nun freigegeben werden. Nach {windowRun} steht die vollständige Bereinigung:'
tutorial.lifecycle.guidance: 'Geben Sie die Swapchain vor ihrem nativen Fenster und den Kontext nach seinen Ressourcen frei. Eingereichte Befehlspuffer werden von der Warteschlange wiederverwendet; die Ausgabetextur wird von der Swapchain verwaltet. Beide benötigen daher keinen eigenen {dispose}-Aufruf.'
-tutorial.lifecycle.title: 'Frame-Ablauf und Bereinigung'
tutorial.pipeline.behavior: 'Erstellen Sie nach dem Eingabelayout die Pipeline:'
tutorial.pipeline.context: '{cullNone} deaktiviert das Face-Culling. Das Dreieck wird dadurch gezeichnet, unabhängig davon, ob seine Vertices im oder gegen den Uhrzeigersinn angeordnet erscheinen.'
tutorial.pipeline.description: 'Eine {graphicsPipeline} verbindet das Vertexlayout und die beiden Shader mit den Einstellungen für die Zusammenstellung der Primitive und die Ausgabe in Attachments.'
-tutorial.pipeline.details: 'Die Shader verarbeiten Vertices und Fragmente. Die übrigen Pipeline-Einstellungen bestimmen die Primitivzusammenstellung, das Face-Culling, den Tiefentest und das Blending:'
tutorial.pipeline.guidance: 'Das Farbformat muss dem Renderpass-Attachment entsprechen und wird deshalb aus {swapChainDescFormat} übernommen. {count1} legt ein Sample pro Pixel fest.'
tutorial.pipeline.item: '{triangleList} setzt jeweils drei aufeinanderfolgende Vertices zu einem Dreieck zusammen.'
tutorial.pipeline.notes: '{depthNone} deaktiviert Tiefentest und Tiefenschreiben entsprechend dem fehlenden Tiefen-Attachment.'
@@ -428,28 +417,25 @@ tutorial.pipeline.reference: '{opaque} deaktiviert Blending. Die Fragmentfarbe e
tutorial.pipeline.title: 'Grafikpipeline'
tutorial.pipeline.usage: 'Shader-Objekte dürfen nach der Pipeline-Erstellung freigegeben werden. Geben Sie die Pipeline dagegen erst nach Abschluss des Renderings frei und ergänzen Sie dafür {pipelineDispose} vor {vertexBufferDispose} in der Bereinigung.'
tutorial.presentation.title: 'Grafikkontext und Präsentation'
-tutorial.project.context: 'Aktivieren Sie {emphasis} ({allowUnsafeBlocks}) in den Buildeinstellungen. Die nativen Fensteraufrufe und der Vertexupload benötigen unsicheren Code.'
+tutorial.project.context: 'Aktivieren Sie {emphasis} ({allowUnsafeBlocks}) in den Buildeinstellungen. Die nativen Aufrufe der Fensterhilfsklasse und der Vertexupload benötigen unsicheren Code.'
tutorial.project.context.emphasis: Unsicheren Code zulassen
tutorial.project.description: 'Erstellen Sie ein C#-Konsolenprojekt namens {firstTriangle} mit .NET 10 als Zielframework.'
tutorial.project.details: 'Fügen Sie dem Projekt die folgenden NuGet-Pakete hinzu:'
-tutorial.project.guidance: '{zenithNET} liefert die gemeinsame API, die drei Backend-Pakete ihre Plattformimplementierungen. {zenithNETCompiler} übersetzt die unten eingeführten Slang-Shader für das Backend. Silk.NET übernimmt Fenster und Ereignisse.'
+tutorial.project.guidance: '{zenithNET} liefert die gemeinsame Grafik- und Compute-API; die drei Grafik-API-Pakete implementieren sie. {zenithNETCompiler} kompiliert Slang-Shader für die gewählte API.'
tutorial.project.title: 'Projekteinrichtung'
-tutorial.requirements.context: 'Das {link} und sein {detail} dienen als Referenzimplementierungen für dieses Tutorial.'
-tutorial.requirements.context.detail: gemeinsamer Host
-tutorial.requirements.context.link: Hallo-Dreieck-Beispiel
-tutorial.requirements.description: 'Sie benötigen das {emphasis} und C#-Grundkenntnisse. Die Anwendung verwendet das Zielframework {net10}. GPU und Treiber müssen das für Ihre Plattform gewählte Backend unterstützen:'
+tutorial.requirements.description: 'Sie benötigen das {emphasis} und C#-Grundkenntnisse. GPU und Treiber müssen für Ihre Plattform folgende Grafikfunktionen unterstützen:'
tutorial.requirements.description.emphasis: .NET 10 SDK
-tutorial.requirements.guidance: 'Zenith.NET rendert in ein von der Anwendung bereitgestelltes Präsentationsziel. Silk.NET.Windowing erstellt das Fenster und verarbeitet Ereignisse. Unter macOS dient ein in {cAMetalLayerCs} repräsentierter Metal-Layer als Ziel; der Fenster-Helper verbindet ihn mit dem Fenster.'
-tutorial.requirements.table.headings.graphicsBackend: Grafik-Backend
+tutorial.requirements.guidance: 'Zenith.NET rendert in ein von der Anwendung bereitgestelltes natives Präsentationsziel. Silk.NET.Windowing erstellt das Fenster und verarbeitet seine Ereignisse.'
+tutorial.requirements.table.headings.graphicsBackend: 'Grafikunterstützung'
tutorial.requirements.table.headings.platform: Plattform
-tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 mit VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux (X11 oder XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: Metal 4
tutorial.requirements.table.macOS.platform: macOS
-tutorial.requirements.table.windows.graphicsBackend: DirectX 12
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 mit Shader Model 6.6'
tutorial.requirements.table.windows.platform: Windows
tutorial.requirements.title: 'Voraussetzungen'
-tutorial.resize.context: 'Erstellen und starten Sie die Anwendung erneut. Auch beim Ändern der Fenstergröße sollte der Hintergrund das gesamte Fenster ausfüllen: Jeder neue Renderpass übernimmt die Abmessungen des angepassten Attachments für Viewport und Scissor. Behalten Sie den Render-Callback bei; in diesem Pass wird später das Dreieck gezeichnet.'
+tutorial.resize.context: 'Erstellen und starten Sie die Anwendung erneut. Auch beim Ändern der Fenstergröße sollte der Hintergrund das gesamte Fenster ausfüllen. Behalten Sie den Render-Callback bei; in diesem Pass wird später das Dreieck gezeichnet.'
tutorial.resize.description: 'Die Swapchain muss Änderungen der Framebuffer-Größe übernehmen. Registrieren Sie nach dem Render-Callback und vor {windowRun} einen Callback für {framebufferResize}:'
tutorial.resize.details: 'Reagieren Sie auf {link}, die in Pixeln angegeben werden, statt auf Änderungen der logischen Fenstergröße. Wird beim Minimieren eine der beiden Framebuffer-Abmessungen null, lässt der Resize-Callback die Swapchain unverändert. Auch der Render-Callback kehrt bei einer Nullgröße sofort zurück. Das Rendering wird erst fortgesetzt, wenn wieder eine nutzbare Größe vorliegt.'
tutorial.resize.details.link: Framebuffer-Größenänderungen
@@ -465,47 +451,29 @@ tutorial.shaders.compilation.guidance: '{zenithCompiler} kompiliert den Quelltex
tutorial.shaders.compilation.title: 'Shader kompilieren'
tutorial.shaders.context: '{fSInput} verbindet die beiden Shader-Stufen. Der Vertex-Shader schreibt eine Position im Clipraum nach {sVPOSITION}; daraus ermittelt die GPU den sichtbaren Teil des Dreiecks. {cOLOR0} enthält die Vertexfarbe, die vor der Übergabe an den Fragment-Shader über das Dreieck interpoliert wird. Typ und Semantik dieses Feldes müssen zwischen den Stufen übereinstimmen.'
tutorial.shaders.description: 'Shader sind Programme, die auf der GPU laufen. Der Vertex-Shader bestimmt die Position jedes Vertex, der Fragment-Shader die Farbe an den vom Dreieck bedeckten Bildpositionen. Beide Stufen stehen in einer Slang-Datei und haben jeweils einen eigenen Einstiegspunkt, also eine Funktion, mit der die Ausführung beginnt.'
-tutorial.shaders.details: 'Erstellen Sie {triangleSlang} mit diesen Eingabe- und Ausgabestrukturen:'
+tutorial.shaders.details: 'Erstellen Sie {triangleSlang} im Projektstamm mit diesen Eingabe- und Ausgabestrukturen:'
tutorial.shaders.fragment.description: 'Ergänzen Sie den Fragment-Einstiegspunkt in derselben Datei:'
tutorial.shaders.fragment.details: 'Die Rasterisierung ermittelt die vom Dreieck bedeckten Bildpositionen und erzeugt dort Fragmente. Jedes Fragment erhält eine aus den drei Vertexfarben interpolierte Farbe. {fSMain} gibt diese Farbe zurück; {sVTARGET} leitet das Ergebnis an das erste Farb-Attachment weiter.'
tutorial.shaders.fragment.title: 'Fragment-Shading'
tutorial.shaders.guidance: '{vSInput} definiert die Vertex-Shader-Eingaben. {pOSITION0} und {cOLOR0} identifizieren Attribute über ihre Semantik; C#-Feldnamen stellen diese Zuordnung nicht her.'
tutorial.shaders.title: 'Shader-Stufen'
tutorial.shaders.vertex.description: 'Ergänzen Sie den Vertex-Einstiegspunkt in {triangleSlang}:'
-tutorial.shaders.vertex.details: 'Die GPU ruft den Einstiegspunkt für jeden Vertex auf, ergänzt die homogene Koordinate {w} und übergibt die Farbe. Nach der Vertexverarbeitung wird die Position durch w geteilt. Hier ist w = 1; x, y und z bleiben unverändert und entsprechen normalisierten Gerätekoordinaten.'
+tutorial.shaders.vertex.details: 'Die GPU führt diese Funktion für jeden Eingabevertex aus. Die Funktion ergänzt die Position um die vierte Komponente {w} und gibt die Farbe weiter. Nach der Vertexverarbeitung teilt die GPU x, y und z durch w und erhält so normalisierte Gerätekoordinaten. Bei w = 1 bleiben diese Werte unverändert.'
tutorial.shaders.vertex.title: 'Vertex-Shading'
tutorial.surface.description: 'Definieren Sie das native Präsentationsziel {emphasis}:'
tutorial.surface.description.emphasis: nach {windowCenter} und vor {windowRun}
tutorial.surface.details: 'Der Framebuffer ist das Fensterbild in Pixeln. {surface} beschreibt das native Präsentationsziel und seine Abmessungen; {framebufferSize} liefert die Pixelgröße. Bei aktiver Anzeigeskalierung kann sie von der logischen Fenstergröße abweichen.'
-tutorial.surface.guidance: 'Die Oberflächenbeschreibung liefert die nativen Handles des gewählten Backends: ein Win32-Fenster unter Windows, X11-Display und -Fenster unter Linux oder den angebundenen Metal-Layer unter macOS.'
+tutorial.surface.guidance: 'Die Oberflächenbeschreibung enthält die nativen Handles für die gewählte Grafik-API: ein Win32-Fenster unter Windows, ein X11-Display und -Fenster unter Linux oder den angebundenen Metal-Layer unter macOS.'
tutorial.surface.title: 'Native Oberfläche'
tutorial.swapChain.context: 'Die Swapchain hängt von Kontext und Fenster ab. Ersetzen Sie {windowDispose} am Ende von {programCs} durch diese Freigabereihenfolge:'
tutorial.swapChain.description: 'Erstellen Sie unmittelbar nach der Oberflächenbeschreibung die Swapchain:'
tutorial.swapChain.details: 'Die {swapChain} verwaltet die angezeigten Bilder. {drawable} liefert das aktuelle Bild als {texture}, den Bildressourcentyp der API. Nach dem Rendering fordert {present} die Anzeige an und wechselt zur nächsten Ausgabetextur.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} speichert vier 8-Bit-Kanäle in Blau-, Grün-, Rot- und Alpha-Reihenfolge. {uNorm} bildet die Ganzzahlen von 0 bis 255 auf den Bereich von 0 bis 1 ab. Der Shader gibt die Farbe weiterhin in der logischen RGBA-Reihenfolge aus; das Format bestimmt ihre Speicherung. Die Pipeline übernimmt das Farbformat aus {swapChainDescFormat}, damit es zum Attachment passt.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} speichert vier 8-Bit-Kanäle in Blau-, Grün-, Rot- und Alpha-Reihenfolge. {uNorm} bildet die Ganzzahlen von 0 bis 255 auf den Bereich von 0 bis 1 ab. Der Shader gibt die Farbe weiterhin in der logischen RGBA-Reihenfolge aus; das Format bestimmt ihre Speicherung.'
tutorial.swapChain.title: 'Swapchain'
tutorial.title: Erstes Dreieck
-tutorial.troubleshooting.description: 'Konsolendiagnosen und die drei Kontrollpunkte grenzen den Fehler ein:'
-tutorial.troubleshooting.details: 'Der {link} und der {detail} dienen als Referenz für Vertexdaten, Eingabelayout und Zeichenbefehle. Das Beispiel verwaltet Fenster und Befehlseinreichung in einem gemeinsamen Host; dieses Tutorial belässt den Anwendungsablauf in {programCs}. Das Beispiel {context} ergänzt indexiertes Zeichnen, Transformationen und Tiefentests.'
-tutorial.troubleshooting.details.context: Rotierender Würfel
-tutorial.troubleshooting.details.detail: Slang-Shader
-tutorial.troubleshooting.details.link: Beispiel-Renderer
-tutorial.troubleshooting.table.backend.check: Überprüfen Sie, ob das ausgewählte Backend vom Gerät und dem installierten Grafiktreiber unterstützt wird.
-tutorial.troubleshooting.table.backend.symptom: Backend-Erstellung schlägt fehl
-tutorial.troubleshooting.table.drawing.check: Überprüfen Sie die Upload-Größe, das Eingabelayout, die Pipeline-Auswahl und die Platzierung der Zeichenbefehle innerhalb des Renderpasses.
-tutorial.troubleshooting.table.drawing.symptom: Der Hintergrund erscheint, aber das Dreieck nicht
-tutorial.troubleshooting.table.headings.check: Prüfung
-tutorial.troubleshooting.table.headings.symptom: Symptom
-tutorial.troubleshooting.table.input.check: Überprüfen Sie den Stride von 28 Bytes und die Positions-/Farboffsets von 0 und 12.
-tutorial.troubleshooting.table.input.symptom: 'Vertexpositionen oder -farben sind fehlerhaft'
-tutorial.troubleshooting.table.shaders.check: Überprüfen Sie die kopierte Datei {triangleSlang}, die Schreibweise des Einstiegspunkts und die vom Compiler gemeldete Diagnose.
-tutorial.troubleshooting.table.shaders.symptom: Der Schritt mit der Hintergrundfarbe funktioniert, aber das Laden der Shader schlägt fehl
-tutorial.troubleshooting.table.window.check: Bestätigen Sie, dass das .NET-Projekt kompiliert wird und der reine Fensterschritt in einer Desktop-Sitzung ausgeführt wird. Überprüfen Sie unter Linux, ob X11 oder XWayland verfügbar ist.
-tutorial.troubleshooting.table.window.symptom: Es öffnet sich kein Fenster
-tutorial.troubleshooting.title: 'Fehlerdiagnose'
tutorial.window.description: 'Laden Sie {cocoaHelperCs} in das Projekt herunter. Die Hilfsklasse bindet den Metal-Layer an das macOS-Fenster.'
-tutorial.window.details: 'Ersetzen Sie den erzeugten Inhalt von {programCs} durch den folgenden Code. Er verwendet Top-Level-Anweisungen, die ohne explizite {main}-Methode der Reihe nach laufen. Die folgenden Abschnitte geben jeweils die Stelle für zusätzlichen Code an:'
-tutorial.window.guidance: '{graphicsAPINone} überlässt den Grafikkontext Zenith.NET. {initialize} erstellt das native Fenster und macht die Handles des Fenstersystems verfügbar. {center} platziert das Fenster in der Bildschirmmitte. {run} verarbeitet Ereignisse bis zum Schließen; danach gibt {dispose} das Fenster frei.'
+tutorial.window.details: 'Ersetzen Sie den Inhalt von {programCs} durch den folgenden Code:'
+tutorial.window.guidance: '{graphicsAPINone} verhindert, dass Silk.NET einen eigenen Grafikkontext für das Fenster erstellt; die Anwendung erstellt später einen Zenith.NET-Kontext. {initialize} erstellt das native Fenster und macht die Handles des Fenstersystems verfügbar. {center} platziert es in der Bildschirmmitte. {run} verarbeitet Ereignisse bis zum Schließen; danach gibt {dispose} das Fenster frei.'
tutorial.window.notes: 'Erstellen und starten Sie die Anwendung. Prüfen Sie, ob sich das Fenster öffnen, verschieben, in der Größe ändern und schließen lässt. Sein Inhalt ist noch nicht definiert, da keine Renderbefehle eingereicht wurden. Schließen Sie das Fenster, bevor Sie fortfahren.'
tutorial.window.title: 'Fenstererstellung'
ui.action.copy: Kopieren
@@ -525,11 +493,11 @@ ui.api.noNamespaceTypes: Keine Typen in diesem Namespace.
ui.api.noTypes: Keine passenden Typen.
ui.api.types: Typen
ui.content.reference: Referenz
-ui.content.source: Quellcode
+ui.content.examples: Codebeispiele
ui.content.tutorial: Tutorial
ui.contents.close: Inhaltsverzeichnis schließen
ui.contents.open: Inhaltsverzeichnis öffnen
-ui.contents.title: Inhalt
+ui.contents.title: Inhaltsverzeichnis
ui.footer.caption: 'Modernes RHI für .NET'
ui.footer.label: Fußzeile
ui.language.label: Sprache
@@ -562,7 +530,6 @@ ui.reference.exceptions: Ausnahmen
ui.reference.extensionMethods: Erweiterungsmethoden
ui.reference.fields: Felder
ui.reference.implementations: Explizite Schnittstellenimplementierungen
-ui.reference.implements: Implementiert
ui.reference.inheritance: Vererbung
ui.reference.inheritedMembers: Geerbte Member
ui.reference.interfaces: Schnittstellen
diff --git a/documents/locales/de-DE/translation.md b/documents/locales/de-DE/translation.md
index 6896825a..997cc6b2 100644
--- a/documents/locales/de-DE/translation.md
+++ b/documents/locales/de-DE/translation.md
@@ -74,6 +74,8 @@ Vor der Abgabe Schlüssel und Platzhalter abgleichen. Startseite, Learn-Einstieg
| command queue | Befehlswarteschlange |
| drawable | Ausgabetextur des aktuellen Frames; `Drawable` bleibt unverändert, nicht grundsätzlich als Swapchain-Bild bezeichnen |
| graphics context | Grafikkontext |
+| graphics API | Grafik-API; DirectX 12, Metal 4 oder Vulkan 1.4 |
+| implementation | Implementierung der Grafik-API; für technische Unterschiede zwischen den Implementierungen |
| pipeline | Pipeline |
| readback | Rücklesen von GPU-Daten |
| render pass | Renderpass |
diff --git a/documents/locales/en-US/strings.yml b/documents/locales/en-US/strings.yml
index aad0d256..5ccd498d 100644
--- a/documents/locales/en-US/strings.yml
+++ b/documents/locales/en-US/strings.yml
@@ -1,8 +1,8 @@
### YamlMime:Resources
concepts.execution.context.description:
- A {graphicsContext} connects the application to a GPU device through a particular
- backend and provides its graphics, compute, and transfer queues. Resources used together must belong to the same
- context; buffers, textures, shaders, pipelines, and their handles cannot be bound across contexts.
+ A {graphicsContext} connects the application to a GPU device through the selected graphics API and provides
+ graphics, compute, and transfer queues. Resources used together must belong to the same context; buffers,
+ textures, shaders, pipelines, and their handles cannot be bound across contexts.
concepts.execution.context.details:
'{capabilities} reports the device name and supported features. Use {rayTracingSupported}
and {meshShadingSupported} to check support before creating the resources for those workloads. The {link} and
@@ -46,10 +46,9 @@ concepts.execution.pipelines.guidance.link: triangle's render callback
concepts.execution.pipelines.title: Pipeline state
concepts.execution.queues.description: '{graphicsQueue} is the usual starting point for a frame that combines drawing,
computation, and copies. Keeping dependent operations on one queue simplifies their ordering.'
-concepts.execution.queues.details: Separate queues allow independent workloads to be submitted separately, but they
- do not necessarily correspond to independent hardware engines. Use additional queues when the work can benefit
- from overlapping execution. When one queue uses data produced by another, connect their submissions with an explicit
- dependency.
+concepts.execution.queues.details: Additional queues can help overlap independent workloads, although they do not
+ necessarily map to independent hardware engines. When one queue uses data produced by another, connect their
+ submissions with an explicit dependency.
concepts.execution.queues.guidance:
Within a queue, dependent operations can also require barriers or texture transitions
so that later accesses observe earlier writes. These memory dependencies are distinct from submission order; {link}
@@ -82,9 +81,9 @@ concepts.platforms.description: Presentation can be managed by the application o
determines who acquires the current frame's output texture, records and submits the frame, and presents the result.
That output texture is called the drawable.
concepts.platforms.frame.context: Record pipeline bindings and draw commands inside the pass, then end it before
- the handler returns. The control submits the commands and presents the result. The handler must not submit the
- command buffer or dispose either supplied object. If it changes the drawable's layout, restore {colorAttachment}
- before returning so the control can perform its final transition.
+ the handler returns. The handler must not submit the command buffer or dispose either supplied object. If
+ it changes the drawable's layout, restore {colorAttachment} before returning so the control can perform its
+ final transition.
concepts.platforms.frame.description: The controls implement {iZenithView}. The application assigns {graphicsContext},
updates scene data in {updateRequested}, and records commands in {renderRequested} using the supplied {renderEventArgs}.
concepts.platforms.frame.details: For each frame, the control acquires a drawable and a command buffer, transitions
@@ -95,20 +94,15 @@ concepts.platforms.frame.guidance: 'Add {usingZenithNET} to the file. For an ini
concepts.platforms.frame.notes: The initial transition uses {undefined}, which allows the previous image contents
to be discarded. Draw or clear the full image on each frame. Keep accumulated or cached rendering in an application-owned
texture, then draw that texture into the control's drawable.
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} provides the default color format used by
- these integrations.'
concepts.platforms.frame.title: Rendering through a UI control
concepts.platforms.integration.context: WinForms, WPF, and the Windows WinUI integration run on Windows. For MAUI,
install the workload for the target platform and register the control handler with {useZenithView}, as shown in
{extensionsCs}.
concepts.platforms.integration.description: 'The event interface is shared, but the presentation mechanism depends
on the framework:'
-concepts.platforms.integration.details: These implementations differ in how the GPU image reaches the UI. Bitmap
- readback copies pixels into CPU memory before display. Shared-texture interop avoids that CPU copy but can still
- require GPU copies and synchronization. Consider this presentation path, as well as the shared {renderRequested}
- event, when choosing an integration.
-concepts.platforms.integration.guidance: Add the integration package for your UI framework through NuGet. For Avalonia,
- use {avaloniaPackage}.
+concepts.platforms.integration.details: UI integrations present GPU images in different ways. Bitmap readback copies
+ pixels into CPU memory before display. Shared-texture interop avoids that copy but may still require GPU copies
+ and synchronization. Consider the presentation path alongside the shared {renderRequested} event.
concepts.platforms.integration.table.avalonia.integration: Avalonia
concepts.platforms.integration.table.avalonia.presentation:
Renders to a texture and downloads pixels into a {writeableBitmap}.
@@ -119,7 +113,7 @@ concepts.platforms.integration.table.maui.integration: .NET MAUI
concepts.platforms.integration.table.maui.presentation: Uses native surfaces on Android, iOS and Mac Catalyst, and
shared-texture composition on Windows. See the {link}.
concepts.platforms.integration.table.maui.presentation.link: platform implementations
-concepts.platforms.integration.table.uno.integration: Uno path
+concepts.platforms.integration.table.uno.integration: Uno Platform
concepts.platforms.integration.table.uno.presentation: Downloads pixels into a {writeableBitmap}. See {zenithViewUnoCs}.
concepts.platforms.integration.table.winForms.integration: WinForms
concepts.platforms.integration.table.winForms.presentation: Creates a Zenith.NET swap chain for the control's {hWND}.
@@ -152,9 +146,10 @@ concepts.platforms.ownership.description: The application owns the assigned cont
the control owns its presentation resources. When the view's {graphicsContext} changes, the scheduler recreates
the control's resources for the new context. Recreate the application's pipelines, buffers, and textures for that
context as well.
-concepts.platforms.ownership.details: Before replacing rendering resources, stop the view's frame activity and wait
- for the GPU work that uses them. Only then release the old resources or context. The application remains responsible
- for releasing the assigned context when the view is removed.
+concepts.platforms.ownership.details: Before replacing rendering resources, stop the view's frame loop
+ and wait for the GPU work that uses them. Then release the old resources. Release the context only after
+ every view has released its presentation resources for that context and all application resources created
+ from it have been released.
concepts.platforms.ownership.guidance:
The shared {frameSchedulerCs} runs frame handlers through the view's UI dispatcher.
Keep those handlers focused on updating scene data and recording commands; lengthy CPU work there also delays
@@ -164,13 +159,13 @@ concepts.platforms.surface.description: The {link} uses Silk.NET to create the w
receives the native window handles and dimensions through a {surface} description, which it uses to create a {swapChain}.
The application remains responsible for the operating-system window.
concepts.platforms.surface.description.link: triangle tutorial
-concepts.platforms.surface.details: 'Surface handles must match the selected backend:'
+concepts.platforms.surface.details: 'Surface handles depend on the graphics API and window system. Common combinations are:'
concepts.platforms.surface.guidance: The sample host in {appCs} supports Windows, macOS, and X11. Its Linux window
supplies Xlib handles, so a Wayland session needs XWayland to run it. A native Wayland application supplies its
display and surface handles through {surfaceWayland}.
concepts.platforms.surface.table.android.backend: Vulkan on Android.
concepts.platforms.surface.table.apple.backend: Metal on Apple platforms.
-concepts.platforms.surface.table.headings.backend: Backend and platform
+concepts.platforms.surface.table.headings.backend: Graphics API and platform
concepts.platforms.surface.table.headings.factory: Surface factory
concepts.platforms.surface.table.headings.handles: Handles supplied by the host
concepts.platforms.surface.table.wayland.backend: Vulkan with a native Wayland host.
@@ -188,8 +183,7 @@ concepts.resources.allocation.description: Use a {heap} when the application nee
concepts.resources.allocation.details: For each resource, call {contextGetSizeAndAlignment} with the buffer or texture
description that will be used to create it. Reserve the returned size at an offset that is a multiple of the returned
alignment, within the heap's bounds and without overlapping another live allocation. Texture sizes may include
- backend-specific padding, so pixel count and bytes per pixel alone are insufficient to calculate their allocation
- size.
+ padding, so pixel count and bytes per pixel alone are insufficient to calculate their allocation size.
concepts.resources.allocation.guidance: A buffer placed in a heap must specify the same residency as that heap.
For texture storage, use a GPU-only heap.
concepts.resources.allocation.title: Heap allocation
@@ -259,11 +253,12 @@ concepts.resources.transfers.guidance: 'To submit transfers together with other
concepts.resources.transfers.item: During an upload call, the library copies the source data into temporary upload
storage, called staging memory. The GPU later reads from this storage, so the application's source pointer is
needed only until the call returns.
-concepts.resources.transfers.notes: For texture transfers, row stride is the byte distance between successive rows
- of CPU data; slice stride is the distance between successive depth slices. These values let the transfer copy
- the CPU data into or out of the texture's GPU storage. {link} explains why GPU completion and delivery to a download
- destination are separate steps.
-concepts.resources.transfers.notes.link: Synchronization
+concepts.resources.transfers.layouts: Recorded texture transfers do not include layout transitions. Uploads
+ require {copyDst}; downloads require {copySrc}. Record transitions to these layouts before the copy and to
+ the layout required by the next use afterward.
+concepts.resources.transfers.notes: For texture transfers, row stride is the byte distance between successive
+ rows of CPU data; slice stride is the distance between successive depth slices. These values let the transfer
+ copy the CPU data into or out of the texture's GPU storage.
concepts.resources.transfers.table.bufferDownload.transfer: Copies directly from mapped memory for {cpuReadOnly}.
Otherwise, submits the download to the transfer queue and waits for it to finish.
concepts.resources.transfers.table.bufferUpload.transfer: Copies directly into mapped memory for {cpuWriteOnly}.
@@ -273,15 +268,15 @@ concepts.resources.transfers.table.headings.transfer: Transfer behavior
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: Submits the copy and its texture transitions to the
graphics queue, then waits for completion. The selected subresource is left in the requested final layout.
-concepts.resources.transfers.title: Immediate and recorded transfers
+concepts.resources.transfers.title: Immediate and command buffer transfers
concepts.resources.usages.description: '{bufferUsages} and {textureUsages} are flag enums for declaring resource
roles. Assign them to {bufferDescUsages} and {textureDescUsages}, respectively. When a resource serves several
roles, combine the required members with {value}.'
concepts.resources.usages.title: Resource usages
concepts.resources.views.description: A {bufferView} describes a region of a buffer and how its data is interpreted.
A {textureView} selects a subresource range and a compatible texture type and format. Both refer to existing storage,
- with the usages declared when that storage was created. View ranges describe access; they do not provide consistent
- shader bounds checking across backends.
+ with the usages declared when that storage was created. View ranges describe access; they do not guarantee consistent
+ shader bounds checking.
concepts.resources.views.details: A resource's own handle provides its default view. Create a separate view to select
a different region or compatible interpretation. Keep both the view and its backing resource alive until the GPU
has finished using them; a resource handle does not retain either object. When replacing either one, update any
@@ -297,12 +292,11 @@ concepts.shaders.binding.description: '{setConstantBuffer} selects an existing b
concepts.shaders.binding.details: 'With a command buffer, compute pipeline, populated constant buffer, and thread-group
counts ready, record the dispatch in this order. Select the pipeline first, because the constant-buffer binding
applies to that pipeline:'
-concepts.shaders.binding.guidance: Here, {commandBuffer} records a dispatch using {computePipeline} and the parameters
- stored in {constantBuffer}. The buffer requires {bufferUsagesConstant} usage, and offset 0 selects its beginning.
- If several constant records share one buffer, each record's starting offset must also meet the backend's binding
- alignment, independently of the layout of fields within the record.
+concepts.shaders.binding.guidance: The constant buffer requires {bufferUsagesConstant} usage. If several constant
+ records share one buffer, each record's starting offset must meet the required binding alignment. This is separate
+ from the layout of fields within each record.
concepts.shaders.binding.notes: '{resourceHandle} contains two 32-bit fields whose interpretation depends on the
- backend. Its values are valid only within the context that created the resource.'
+ graphics API implementation. Its values are valid only within the context that created the resource.'
concepts.shaders.binding.reference: Retain the resource and any view used to obtain its handle until the shader's
final access completes. Replacing a texture or view requires updating constants that still contain the old handle.
The ownership rules are described in {link}.
@@ -317,8 +311,8 @@ concepts.shaders.binding.table.samplerHandle.access: Texture sampling state
concepts.shaders.binding.table.textureSampledHandle.access: Texture reads
concepts.shaders.binding.table.textureStorageHandle.access: Storage-texture reads and writes
concepts.shaders.binding.title: Constant buffers and resource handles
-concepts.shaders.compilation.description: "{zenithCompiler} compiles a named Slang entry point into a {shaderDesc}.
- The context's {graphicsApi} selects the required target: DXIL for DirectX 12, a Metal library for Metal, or SPIR-V
+concepts.shaders.compilation.description: "{zenithCompiler} compiles a Slang entry point and returns a {shaderDesc}.
+ The context's {graphicsApi} selects the output format: {dxil} for DirectX 12, {metallib} for Metal, or {spirv}
for Vulkan."
concepts.shaders.compilation.details: 'With a graphics context named {context} already created, compile the triangle
shader from the copy placed beside the executable:'
@@ -352,9 +346,10 @@ concepts.shaders.layout.guidance: Shader parameters can include resource handles
identifies storage that already exists, so copying the handle into a constant buffer does not copy the resource's
contents.
concepts.shaders.layout.notes: 'The matching declaration in {computeShaderSlang} is:'
-concepts.shaders.layout.reference: The two dimensions occupy the first eight bytes, followed by two eight-byte handles.
- The C# sample reserves 256 bytes for the complete record. For another record, determine its size from its own
- fields and the required layout and alignment.
+concepts.shaders.layout.reference: 'The C# fields occupy the first 24 bytes: eight for the dimensions and eight
+ for each handle. The 256-byte record leaves the remaining bytes as padding. For a different parameter block,
+ match the field offsets to its shader layout. If multiple records share a buffer, include enough padding
+ between them to meet the required binding alignment.'
concepts.shaders.layout.title: Data layout
concepts.shaders.matrices.description: The compiler selects row-major matrix storage, keeping each row contiguous.
The {link} stores three {matrix4x4} values at offsets 0, 64, and 128. Its {detail} applies {mulVectorMatrix} in
@@ -366,15 +361,14 @@ concepts.shaders.matrices.details: Storage order specifies how matrix elements a
concepts.shaders.matrices.title: Matrix conventions
concepts.shaders.title: Shader Data and Binding
concepts.synchronization.backends.description: DirectX 12 and Vulkan encode texture transitions as layout and access
- changes. Metal has no equivalent operation in Zenith.NET's {transition} implementation. The Metal backend instead
+ changes. Metal has no equivalent operation in Zenith.NET's {transition} implementation. On Metal, Zenith.NET
groups commands into render and compute encoders and inserts visibility barriers when an encoder ends. Dependent
operations within one encoder, such as successive compute dispatches, use explicit {barrier} calls.
-concepts.synchronization.backends.details: In the {link}, starting the graphics render pass ends the compute encoder,
- making its output visible to the graphics work. Two successive compute dispatches remain in the same encoder,
- so their dependency needs a barrier even if a texture transition is recorded between them. This is why portable
- command sequences account for access dependencies as well as texture layouts.
+concepts.synchronization.backends.details: In the {link}, starting the graphics render pass ends the compute
+ encoder, making its output visible to the graphics work. Two successive compute dispatches remain in the
+ same encoder, so their dependency needs a barrier even if a texture transition is recorded between them.
concepts.synchronization.backends.details.link: compute sample
-concepts.synchronization.backends.title: Backend behavior
+concepts.synchronization.backends.title: Synchronization across graphics APIs
concepts.synchronization.barriers.context: Choose stages that include the relevant accesses and are supported by
the queue. {barrierStagesAll} includes every supported stage; select a narrower set when the dependency only involves
those stages.
@@ -384,8 +378,7 @@ concepts.synchronization.barriers.description: 'Consider two compute dispatches
concepts.synchronization.barriers.details: The first argument identifies the stages that produced the data; the
second identifies the stages that will consume it. Together they describe the execution order and memory visibility
required between the two dispatches.
-concepts.synchronization.barriers.guidance: The {link} uses this pattern between simulation steps. Each barrier
- follows the dispatch that produces the data and precedes the dispatch that uses it.
+concepts.synchronization.barriers.guidance: The {link} uses this pattern between simulation steps.
concepts.synchronization.barriers.guidance.link: FluidTank simulation
concepts.synchronization.barriers.title: Pipeline barriers
concepts.synchronization.dependencies.description: For each resource, identify the accesses that touch the same
@@ -393,9 +386,9 @@ concepts.synchronization.dependencies.description: For each resource, identify t
layout and presentation requirements still apply. CPU updates and resource disposal also need to wait until the
GPU has finished using the affected storage.
concepts.synchronization.dependencies.details: 'The appropriate mechanism depends on where the operations execute:'
-concepts.synchronization.dependencies.guidance: A workload may need more than one mechanism. For example, a texture
- produced on another queue needs a submission dependency and the appropriate layout for its next use. Neither operation
- requires blocking the CPU unless the CPU itself needs to access or release the data.
+concepts.synchronization.dependencies.guidance: When one queue writes a texture that another uses, submit the consumer
+ with a dependency and record any required layout transition. Neither blocks the CPU. Wait for completion before
+ the CPU accesses the data or releases the resource.
concepts.synchronization.dependencies.table.cpuAccess.mechanism: Call {wait} on the relevant completion value.
concepts.synchronization.dependencies.table.cpuAccess.situation: CPU access or resource release depends on GPU completion
concepts.synchronization.dependencies.table.crossQueue.mechanism: Pass the producer's {timelineValue} to the consumer's
@@ -473,7 +466,7 @@ home.entries.reference.category: Reference
home.entries.reference.description: Look up API types, members, and declarations
home.entries.reference.title: API Reference
home.entries.samples.action: Browse samples
-home.entries.samples.category: Examples
+home.entries.samples.category: Code examples
home.entries.samples.description: Working examples of graphics and compute techniques
home.entries.samples.title: Samples
home.entries.title: Documentation
@@ -482,9 +475,9 @@ home.entries.tutorial.category: Tutorial
home.entries.tutorial.description: From an empty project to your first triangle on screen
home.entries.tutorial.title: First Triangle
home.introduction.accent: for .NET
-home.introduction.description: Zenith.NET provides one API for graphics and compute across DirectX, Metal, and Vulkan
+home.introduction.description: Zenith.NET provides one API for graphics and compute across DirectX 12, Metal 4, and Vulkan 1.4
home.introduction.title: Cross-platform graphics{lineBreak}{accent}
-home.meta.description: Cross-platform graphics and compute for .NET with one API for DirectX, Metal, and Vulkan
+home.meta.description: Cross-platform graphics and compute for .NET with one API for DirectX 12, Metal 4, and Vulkan 1.4
home.scene.description: Interactive rotating geometry. Drag or use the arrow keys to adjust the view.
home.scene.label: Geometry display
home.scene.surface: Surface
@@ -509,87 +502,68 @@ learning.title: Learn
reference.description: Reference documentation for resources, commands, and platform integrations
reference.entries.commands.description: Graphics, compute, and transfer commands
reference.entries.commands.label: Record commands
-reference.entries.context.description: GPU resource creation for the selected backend
+reference.entries.context.description: GPU resource creation through a graphics context
reference.entries.context.label: Start here
reference.meta.description: Namespaces, types, and members of Zenith.NET
reference.navigation.core: Core API reference
reference.title: API Reference
-samples.computeShader.description: The sample loads {assetsTexturesShokoPng}, converts it to grayscale in a compute
- dispatch, and displays the output texture. The conversion runs once; later frames display the same result. The
- renderer shows how to bind sampled and writable textures, round up thread-group counts to cover the image, and
- check image bounds in the shader.
+samples.computeShader.description: A compute shader converts a color image to grayscale, demonstrating GPU image
+ processing.
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: Compute Shader
-samples.cube.description: The cube adds indexed drawing, model, view, and projection matrices in a constant buffer,
- and depth testing. Its {d32FloatS8UInt} depth/stencil texture is recreated on resize.
+samples.cube.description: A rotating cube introduces indexed geometry, 3D transformations, and depth testing.
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: Spinning Cube
-samples.description: Each example pairs a C# renderer with its Slang shader and concentrates on a particular technique.
- For the complete application setup and rendering sequence, begin with {link}.
-samples.description.link: First Triangle
+samples.description: These examples cover rendering and compute, from a single triangle to interactive applications
+ and diagnostic tools.
samples.execution.description: Run the {link} project and choose an example from its console menu.
samples.execution.description.link: ZenithTutorials
samples.execution.title: Running the examples
-samples.host.description: "{appCs} initializes the context, window, and swap chain. On each frame it obtains a command
- buffer, invokes the selected renderer, submits the commands, and presents the result. {iRendererCs} defines the
- renderer's update, render, resize, and disposal operations."
-samples.host.details: The compute and ray tracing renderers produce offscreen textures. {texturePresenterCs} and
- {presentTextureSlang} draw those textures into the current drawable; the shared host then submits the commands
- and presents the frame.
-samples.host.title: Host and presentation
-samples.indirectDrawing.description: Indirect drawing renders multiple cube instances from a buffer of indexed draw
- arguments and a structured buffer of per-instance data. The CPU supplies the arguments and updates the transforms.
+samples.indirectDrawing.description: A grid of rotating, individually colored cubes demonstrates indirect drawing
+ from a buffer of draw arguments.
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: Indirect Drawing
-samples.meshShading.description: A task shader culls sphere instances and passes the retained indices to a mesh
- shader that emits geometry. The renderer checks {contextCapabilitiesMeshShadingSupported} before creating the
- pipeline.
+samples.meshShading.description: This sample uses task and mesh shaders to render a grid of colored spheres, skipping
+ spheres outside the camera's view. Requires mesh shading support.
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: Mesh Shading
-samples.rayTracing.description: This example builds bottom-level and top-level acceleration structures for a floor
- and procedural spheres, then performs inline ray queries in a compute shader. It checks {contextCapabilitiesRayTracingSupported}
- before initialization.
+samples.rayTracing.description: This sample uses ray queries to render reflective spheres and shadows on a
+ checkerboard floor. Requires ray tracing support.
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: Ray Tracing
samples.title: Samples
-samples.triangle.description: The triangle associates a vertex buffer with a matching input layout and draws three
- vertices through a graphics pipeline.
+samples.triangle.description: A triangle with smoothly blended vertex colors introduces the basic graphics
+ pipeline.
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: Complete tutorial
samples.triangle.title: Hello Triangle
-samples.workloads.description: The main repository's {link} contains larger applications that reference the library
- source.
+samples.workloads.description: The Zenith.NET repository's {link} contains these applications and utilities.
samples.workloads.description.link: Experiments directory
-samples.workloads.details: The windowed experiments use the same Windows, macOS, and Linux/X11 presentation paths.
- UI controls for Avalonia, WinForms, WPF, WinUI/Uno, and MAUI are covered in {link}, including their frame lifecycle
- and implementation sources.
-samples.workloads.details.link: Platform Integration
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: CornellBox
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: Path tracing, denoising, tone mapping, upscaling,
- and ImGui controls. Requires ray tracing support.
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: An interactive room scene for exploring lighting
+ and reflections. Requires ray tracing support.
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: FluidTank
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: Compute fluid simulation, dependencies between
- simulation stages, and multipass surface rendering.
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: A water simulation in a tank, with surface
+ and particle views.
samples.workloads.table.headings.example: Example
-samples.workloads.table.headings.whatItDemonstratesAndRequires: Techniques and requirements
+samples.workloads.table.headings.whatItDemonstratesAndRequires: Description
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: InkCanvas
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Skia drawing and input handling in a native window.
- Requires the backend and Skia native library for the target platform.
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: A canvas for drawing and erasing freehand
+ strokes.
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: PlatformDetection
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: Attempts to create a context for each backend
- and reports device capabilities. It reports a failed attempt as unsupported; the failure may be due to the device,
- driver, or a missing runtime dependency.
-samples.workloads.title: Larger applications
-tutorial.context.description: A {graphicsContext} connects the application to the GPU through a backend and provides
- the methods used to create rendering resources.
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: A console tool that reports graphics
+ API availability and device features.
+samples.workloads.title: Applications and utilities
+tutorial.context.description: A {graphicsContext} connects the application to the GPU through the selected graphics
+ API and provides methods to create resources for rendering.
tutorial.context.details: 'Insert the context initialization {emphasis}:'
tutorial.context.details.emphasis: after the using directives, before {iWindowWindow}
-tutorial.context.guidance: Each branch selects a backend for the current platform and requests validation. Messages
- from {validationMessage} are printed in the console.
+tutorial.context.guidance: Each branch requests validation for its graphics API. The handler prints any diagnostics
+ reported through {validationMessage}.
tutorial.context.imports: 'Add the following using directives at the top of {programCs}:'
tutorial.context.title: Graphics context
tutorial.description: In this tutorial, you will build a .NET console application that opens a window and draws
@@ -599,13 +573,12 @@ tutorial.details: 'The tutorial has three checkpoints: an empty window, a solid
tutorial.draw.context: 'The arguments to {draw} are:'
tutorial.draw.description: 'In the {windowRender} callback, replace {addTheTriangleDrawCommandsHereLater} with the
following commands, between {beginRenderPass} and {endRenderPass}:'
-tutorial.draw.details: "{setPipeline} selects the shaders and render state. It must precede vertex binding because
- the backend interprets that binding using the pipeline's input layout."
+tutorial.draw.details: "{setPipeline} selects the shaders and render state. Bind the pipeline before the vertex buffer
+ so the pipeline's input layout can determine how vertex data is read."
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} binds the uploaded vertex data at byte offset 0 to input
slot 0, corresponding to the single entry in {inputLayouts}.'
-tutorial.draw.notes: These calls record the draw commands. The existing {submitWait} submits them and waits for
- the GPU to finish; {present} then requests display of the completed image. Keep the clear operation at the start
- of the pass so the area outside the triangle has a defined background color.
+tutorial.draw.notes: Keep the clear operation at the start of the pass so the area outside the triangle has
+ a defined background color.
tutorial.draw.table.firstInstance.meaning: Start instance numbering at zero.
tutorial.draw.table.firstVertex.meaning: Start with the first vertex in the buffer.
tutorial.draw.table.headings.argument: Argument
@@ -632,16 +605,16 @@ tutorial.frame.commands.description: A render pass groups drawing operations tha
tutorial.frame.commands.details: The collection contains one color attachment. {null} specifies that the pass has
no depth/stencil attachment.
tutorial.frame.commands.guidance: '{beginRenderPass} sets the viewport and scissor to cover the whole attachment.
- The viewport maps rendering coordinates to pixel positions; the scissor limits where pixels can be written.'
+ The viewport maps rendering coordinates to pixel positions; the scissor limits which pixels drawing can affect.'
tutorial.frame.commands.title: Clear, submission, and presentation
-tutorial.frame.description: Start by filling the window with a single background color. This operation is called
- clearing. Once the background appears, the surface, command submission, and presentation are working together,
- ready for the triangle's geometry and shaders.
-tutorial.frame.details: 'Silk.NET invokes the render callback when a frame is due. This example does not use the
- elapsed-time argument, so the parameter is named {value}. Register the callback {emphasis}:'
+tutorial.frame.description: Start by filling the window with a solid color, an operation called clearing. If the
+ color appears, command submission and presentation are working. Then add the triangle's vertices and shaders.
+tutorial.frame.details: 'Silk.NET invokes the render callback when a frame is due. Register the callback {emphasis}:'
tutorial.frame.details.emphasis: before {windowRun}
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} returns a command buffer ready for recording. Recording
- defines the GPU workload; execution begins only after submission.'
+tutorial.frame.target.description:
+ A command queue receives recorded work for GPU execution. {graphicsQueueCommandBuffer}
+ returns a command buffer from the graphics queue with recording already in progress. The recorded commands define
+ the GPU workload; execution begins only after submission.
tutorial.frame.target.details:
A texture layout describes the kind of access an operation requires. The first {transition}
prepares the drawable for use as a color attachment. Here, {default} selects mip level 0 and array layer 0, the
@@ -654,10 +627,9 @@ tutorial.frame.title: The first frame
tutorial.geometry.data.description: Add the vertex array {emphasis}. Keep the subsequent resource initialization
before this callback as well, in the order presented.
tutorial.geometry.data.description.emphasis: before {windowRender}
-tutorial.geometry.data.details: 'Each entry constructs a {vertex}; the two inner {new} expressions provide its {vector3}
- position and {vector4} color. The positions form the upper, lower-right, and lower-left corners. The vertex shader
- adds {w} as the fourth position coordinate. With w equal to 1, x and y are also normalized device coordinates:
- -1 and +1 mark the image boundaries, and 0 marks the center. Their interpretation is independent of pixel dimensions.'
+tutorial.geometry.data.details: 'The three positions form the upper, lower-right, and lower-left corners. In
+ this example, x and y use the range -1 to +1 across the image: 0 is the center, positive x points right,
+ and positive y points up.'
tutorial.geometry.data.guidance: Each color has red, green, blue, and alpha components, with alpha set to 1. All
three vertices have z = 0 and lie in the same plane.
tutorial.geometry.data.title: Vertex positions and colors
@@ -665,10 +637,10 @@ tutorial.geometry.description: Each of the triangle's three vertices has a posit
positions to determine the triangle's shape and interpolates the colors across its surface.
tutorial.geometry.format.description: 'Append the vertex declaration {emphasis}:'
tutorial.geometry.format.description.emphasis: at the end of {programCs}, after the cleanup statements
-tutorial.geometry.format.details: '{file} limits the type to {programCs}, and {layoutKindSequential} keeps its fields
- in declaration order. {position} contains three 32-bit floats and starts at byte offset 0; {color} contains four
- and starts at byte offset 12. Each vertex therefore occupies 28 bytes. The input layout will describe this arrangement
- so the GPU can read the fields correctly.'
+tutorial.geometry.format.details: '{layoutKindSequential} keeps the fields in declaration order. {position}
+ contains three 32-bit floats and starts at byte offset 0; {color} contains four and starts at byte offset
+ 12. Each vertex therefore occupies 28 bytes. The input layout will describe this arrangement so the GPU can
+ read the fields correctly.'
tutorial.geometry.format.imports: 'Add these using directives at the top of {programCs} for the vector types and the struct layout attribute:'
tutorial.geometry.format.title: Vertex representation
tutorial.geometry.title: Vertex data
@@ -685,9 +657,8 @@ tutorial.geometry.upload.details: "The allocation size is {sizeofVertexVerticesL
tutorial.geometry.upload.guidance: Allocation does not initialize the buffer's contents. {upload} copies the array
to destination byte offset 0 using the source pointer and byte count supplied in the data description.
tutorial.geometry.upload.imports: 'In {programCs}, add {bufferAlias} to the using directives to distinguish the Zenith.NET buffer type from {systemBuffer}.'
-tutorial.geometry.upload.notes: Add {vertexBufferDispose} immediately before {swapChainDispose} in the cleanup at
- the end of {programCs}. For larger static geometry, {link} discusses GPU-only storage and transfer uploads.
-tutorial.geometry.upload.notes.link: Resource Management
+tutorial.geometry.upload.notes: Add {vertexBufferDispose} immediately before {swapChainDispose} in the cleanup
+ at the end of {programCs}.
tutorial.geometry.upload.title: Buffer allocation and upload
tutorial.input.description: 'The GPU needs to know where each vertex attribute, such as position or color, is stored.
The input layout supplies its format and byte offset. It also sets the stride: the number of bytes from one vertex
@@ -708,21 +679,20 @@ tutorial.input.table.nextVertex.shaderInput: Next input record
tutorial.input.table.vertexColor.format: '{float4} (16 bytes)'
tutorial.input.table.vertexPosition.format: '{float3} (12 bytes)'
tutorial.input.title: Vertex input layout
-tutorial.lifecycle.description: 'Each frame follows this sequence:'
+tutorial.lifecycle.description:
+ For each frame, get the current drawable, transition it for use as a color attachment, clear
+ the background and draw the triangle, transition it for presentation, then submit, wait, and present.
tutorial.lifecycle.details: 'When the window closes, {run} returns and execution continues to the cleanup code.
- Each frame has already waited for its submitted work to finish, so the resources used by those commands can now
+ The render callback has waited for every submitted frame to finish, so the resources used by those commands can now
be released. The complete cleanup after {windowRun} is:'
tutorial.lifecycle.guidance: Release the swap chain before destroying its native window, and release the context
after its resources. Submitted command buffers are recycled by the queue, and the drawable is managed by the swap
chain, so neither needs a separate {dispose} call.
-tutorial.lifecycle.title: Frame lifecycle and cleanup
tutorial.pipeline.behavior: 'After the input layout, create the pipeline:'
tutorial.pipeline.context: '{cullNone} disables face culling, so the triangle is drawn whether its vertices appear
clockwise or counterclockwise.'
tutorial.pipeline.description: A {graphicsPipeline} brings together the vertex layout, the two shaders, and the
settings that determine how primitives are assembled and written to attachments.
-tutorial.pipeline.details: 'The shaders process vertices and fragments. The other pipeline settings control primitive
- assembly, face culling, depth testing, and blending:'
tutorial.pipeline.guidance: The pipeline's color format must match the render-pass attachment, so it is taken from
{swapChainDescFormat}. {count1} specifies one sample per pixel.
tutorial.pipeline.item: '{triangleList} assembles each consecutive group of three vertices into a triangle.'
@@ -736,35 +706,29 @@ tutorial.pipeline.usage:
and add {pipelineDispose} before {vertexBufferDispose} in the cleanup.
tutorial.presentation.title: Graphics context and presentation
tutorial.project.context: Enable {emphasis} ({allowUnsafeBlocks}) in the project's build settings. Native calls
- in the window helper and the vertex upload require unsafe code.
+ in the window helper class and the vertex upload require unsafe code.
tutorial.project.context.emphasis: Allow unsafe code
tutorial.project.description: Create a C# console project named {firstTriangle} targeting .NET 10.
tutorial.project.details: 'Add the following NuGet packages to the project:'
-tutorial.project.guidance: '{zenithNET} provides the shared rendering API, and the three backend packages supply
- its platform implementations. {zenithNETCompiler} compiles the Slang shaders introduced below for the selected
- backend. Silk.NET provides window creation and event processing.'
+tutorial.project.guidance: '{zenithNET} provides the shared graphics and compute API; the three graphics API packages
+ implement it. {zenithNETCompiler} compiles Slang shaders for the selected API.'
tutorial.project.title: Project setup
-tutorial.requirements.context: The {link} and its {detail} provide reference implementations for this tutorial.
-tutorial.requirements.context.detail: shared host
-tutorial.requirements.context.link: Hello Triangle sample
-tutorial.requirements.description: 'You need the {emphasis} and basic C# knowledge. The application targets {net10}.
- Your GPU and driver must support the backend selected for your platform:'
+tutorial.requirements.description: 'You need the {emphasis} and basic C# knowledge. Your GPU and driver must support
+ these graphics capabilities for your platform:'
tutorial.requirements.description.emphasis: .NET 10 SDK
tutorial.requirements.guidance: Zenith.NET renders into a native surface provided by the application. Silk.NET.Windowing
- creates the window and processes its events. On macOS, presentation uses a Metal layer, represented by {cAMetalLayerCs};
- the window helper attaches it to the window.
-tutorial.requirements.table.headings.graphicsBackend: Graphics backend
+ creates the window and processes its events.
+tutorial.requirements.table.headings.graphicsBackend: Graphics support
tutorial.requirements.table.headings.platform: Platform
-tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4
+tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4 with VK_EXT_descriptor_heap
tutorial.requirements.table.linux.platform: Linux (X11 or XWayland)
tutorial.requirements.table.macOS.graphicsBackend: Metal 4
tutorial.requirements.table.macOS.platform: macOS
-tutorial.requirements.table.windows.graphicsBackend: DirectX 12
+tutorial.requirements.table.windows.graphicsBackend: DirectX 12 with Shader Model 6.6
tutorial.requirements.table.windows.platform: Windows
tutorial.requirements.title: Prerequisites
-tutorial.resize.context: 'Build and run the application again. The background should continue to fill the window
- when you resize it: each new render pass sets its viewport and scissor from the resized attachment. Keep the render
- callback in place; the triangle will be drawn inside this pass.'
+tutorial.resize.context: Build and run the application again. The background should continue to fill the window
+ when you resize it. Keep the render callback in place; the triangle will be drawn inside this pass.
tutorial.resize.description:
"The swap chain must follow changes to the framebuffer's size. Register a {framebufferResize}
callback after the render callback and before {windowRun}:"
@@ -799,7 +763,7 @@ tutorial.shaders.context: '{fSInput} connects the two shader stages. The vertex
tutorial.shaders.description: Shaders are programs that run on the GPU. The vertex shader determines each vertex's
position, and the fragment shader determines the color at each covered image location. Both stages will be written
in one Slang file, with a separate entry point—the function where execution begins—for each stage.
-tutorial.shaders.details: 'Create {triangleSlang} with these input and output structures:'
+tutorial.shaders.details: 'Create {triangleSlang} in the project root with these input and output structures:'
tutorial.shaders.fragment.description: 'Append the fragment entry point to the same file:'
tutorial.shaders.fragment.details: Rasterization determines where the triangle covers the image and generates fragments
for those locations. Each fragment receives a color interpolated from the three vertex colors. {fSMain} returns
@@ -809,16 +773,16 @@ tutorial.shaders.guidance: "{vSInput} defines the vertex shader's inputs. {pOSIT
attributes by semantic; the C# field names alone do not establish this mapping."
tutorial.shaders.title: Shader stages
tutorial.shaders.vertex.description: 'Append the vertex entry point to {triangleSlang}:'
-tutorial.shaders.vertex.details: The GPU invokes this entry point for each input vertex. It adds the homogeneous
- coordinate {w} and forwards the color. After vertex processing, position is divided by w. Since w is 1 here, x,
- y, and z are unchanged and may be interpreted directly as normalized device coordinates.
+tutorial.shaders.vertex.details: The GPU runs this function for each input vertex. It adds a fourth position
+ component, {w}, and passes on the color. After vertex processing, the GPU divides x, y, and z by w to obtain
+ normalized device coordinates. With w equal to 1, these values are unchanged.
tutorial.shaders.vertex.title: Vertex shading
tutorial.surface.description: 'Specify the native presentation target {emphasis}:'
tutorial.surface.description.emphasis: after {windowCenter} and before {windowRun}
tutorial.surface.details: The framebuffer is the window's image in pixels. {surface} describes the native presentation
target and its dimensions, and {framebufferSize} gives the size in pixels. With display scaling, this can differ
from the window's logical size.
-tutorial.surface.guidance: 'The surface supplies the native handles needed by the selected backend: a Win32 window
+tutorial.surface.guidance: 'The surface supplies the native handles needed by the selected graphics API: a Win32 window
on Windows, an X11 display and window on Linux, or the attached Metal layer on macOS.'
tutorial.surface.title: Native surface
tutorial.swapChain.context: 'The swap chain depends on both the context and the window. Replace {windowDispose}
@@ -827,42 +791,17 @@ tutorial.swapChain.description: 'Create the swap chain immediately after the sur
tutorial.swapChain.details: The {swapChain} manages the images presented by the window. {drawable} supplies the
current image as a {texture}, the API's image resource. After rendering, {present} requests display of that image
and advances to the next drawable.
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} stores four 8-bit channels in blue, green, red, and alpha order. {uNorm}
- maps integer values 0–255 to values 0–1. Shader output remains a logical RGBA value; the format specifies its
- storage representation. The pipeline will use {swapChainDescFormat} to match this attachment.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} stores four 8-bit channels in blue, green, red, and alpha order.
+ {uNorm} maps integer values 0–255 to values 0–1. Shader output remains a logical RGBA value; the format specifies
+ its storage representation.'
tutorial.swapChain.title: Swap chain
tutorial.title: First Triangle
-tutorial.troubleshooting.description: 'Use console diagnostics and the three checkpoints to identify the failing
- stage:'
-tutorial.troubleshooting.details: The {link} and {detail} provide a reference for the vertex data, input layout,
- and draw operation. That example separates windowing and submission into a shared host; this tutorial retains
- the application flow in {programCs}. {context} introduces indexed drawing, transformations, and depth testing.
-tutorial.troubleshooting.details.context: Spinning Cube
-tutorial.troubleshooting.details.detail: Slang shader
-tutorial.troubleshooting.details.link: sample renderer
-tutorial.troubleshooting.table.backend.check: Check that the selected backend is supported by the device and installed
- graphics driver.
-tutorial.troubleshooting.table.backend.symptom: Backend creation fails
-tutorial.troubleshooting.table.drawing.check: Check the upload size, input layout, pipeline selection and the placement
- of the draw commands inside the render pass.
-tutorial.troubleshooting.table.drawing.symptom: The background appears but the triangle does not
-tutorial.troubleshooting.table.headings.check: Check
-tutorial.troubleshooting.table.headings.symptom: Symptom
-tutorial.troubleshooting.table.input.check: Check the 28-byte stride and the position/color offsets of 0 and 12.
-tutorial.troubleshooting.table.input.symptom: Vertex positions or colors are corrupted
-tutorial.troubleshooting.table.shaders.check: Check the copied {triangleSlang}, entry-point spelling and the compiler's
- reported diagnostic.
-tutorial.troubleshooting.table.shaders.symptom: The clear-color step works, but shader loading fails
-tutorial.troubleshooting.table.window.check: Confirm the .NET project builds and the window-only step runs in a
- desktop session. On Linux, check that X11 or XWayland is available.
-tutorial.troubleshooting.table.window.symptom: No window opens
-tutorial.troubleshooting.title: Troubleshooting
tutorial.window.description: 'Download {cocoaHelperCs} into the project. This helper class attaches the Metal layer to the macOS window.'
-tutorial.window.details: 'Replace the generated {programCs} with the code below. It uses top-level statements, which
- run in order without an explicit {main} method. Each later section will show where to add its code:'
-tutorial.window.guidance: '{graphicsAPINone} leaves graphics-context creation to Zenith.NET. {initialize} creates
- the native window and makes its window-system handles available. {center} places the window in the center of the
- screen. {run} processes events until the window closes, then execution continues to {dispose} to release it.'
+tutorial.window.details: 'Replace the contents of {programCs} with the code below:'
+tutorial.window.guidance: '{graphicsAPINone} tells Silk.NET not to create a graphics context; the application will
+ create a Zenith.NET context later. {initialize} creates the native window and makes its window-system handles
+ available. {center} places the window in the center of the screen. {run} processes events until the window closes,
+ then execution continues to {dispose} to release it.'
tutorial.window.notes: Build and run the application, then check that the window opens, moves, resizes, and closes.
Its contents are not yet defined because no rendering commands have been submitted. Close the window before continuing.
tutorial.window.title: Window creation
@@ -883,7 +822,7 @@ ui.api.noNamespaceTypes: No types in this namespace.
ui.api.noTypes: No matching types.
ui.api.types: Types
ui.content.reference: Reference
-ui.content.source: Source code
+ui.content.examples: Code examples
ui.content.tutorial: Tutorial
ui.contents.close: Close contents
ui.contents.open: Open contents
@@ -920,7 +859,6 @@ ui.reference.exceptions: Exceptions
ui.reference.extensionMethods: Extension methods
ui.reference.fields: Fields
ui.reference.implementations: Explicit interface implementations
-ui.reference.implements: Implements
ui.reference.inheritance: Inheritance
ui.reference.inheritedMembers: Inherited members
ui.reference.interfaces: Interfaces
diff --git a/documents/locales/es-ES/strings.yml b/documents/locales/es-ES/strings.yml
index 768e023d..985f1430 100644
--- a/documents/locales/es-ES/strings.yml
+++ b/documents/locales/es-ES/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: 'Un {graphicsContext} conecta la aplicación con un dispositivo GPU mediante un backend concreto y proporciona sus colas gráfica, de cálculo y de transferencia. Los recursos que se utilizan juntos deben pertenecer al mismo contexto; no se pueden enlazar búferes, texturas, sombreadores, canalizaciones ni sus identificadores entre contextos distintos.'
+concepts.execution.context.description: 'Un {graphicsContext} conecta la aplicación con un dispositivo GPU mediante la API gráfica elegida y proporciona sus colas gráfica, de cálculo y de transferencia. Los recursos que se utilizan juntos deben pertenecer al mismo contexto; no se pueden enlazar búferes, texturas, sombreadores, canalizaciones ni sus identificadores entre contextos distintos.'
concepts.execution.context.details: '{capabilities} indica el nombre del dispositivo y las funciones que admite. Compruebe {rayTracingSupported} y {meshShadingSupported} antes de crear los recursos que necesitan esas funciones. Los ejemplos de {link} y {detail} realizan estas comprobaciones durante la inicialización.'
concepts.execution.context.details.detail: 'sombreado de mallas'
concepts.execution.context.details.link: 'trazado de rayos'
@@ -15,8 +15,8 @@ concepts.execution.ownership.table.commandBuffers.object: 'Búferes de comandos
concepts.execution.ownership.table.commandBuffers.ownership: 'La cola los gestiona y los recicla.'
concepts.execution.ownership.table.headings.object: 'Objeto'
concepts.execution.ownership.table.headings.ownership: 'Responsabilidad de liberación'
-concepts.execution.ownership.table.queues.object: 'Colas de contexto y sus líneas de tiempo'
-concepts.execution.ownership.table.queues.ownership: 'El contexto y las colas las gestionan.'
+concepts.execution.ownership.table.queues.object: 'Colas del contexto y sus líneas de tiempo'
+concepts.execution.ownership.table.queues.ownership: 'El contexto gestiona las colas y cada cola gestiona su línea de tiempo.'
concepts.execution.ownership.table.swapChainDrawable.ownership: 'La cadena de intercambio lo gestiona.'
concepts.execution.ownership.title: 'Propiedad y tiempo de vida'
concepts.execution.pipelines.description: 'Una canalización gráfica define los sombreadores, la disposición de entrada de vértices, el ensamblado de primitivas, los formatos de adjunto y el estado de renderizado. Se selecciona antes de enlazar vértices, índices o constantes. Los formatos y el número de muestras deben coincidir con la pasada de renderizado.'
@@ -26,7 +26,7 @@ concepts.execution.pipelines.guidance.detail: 'ejemplo de cálculo'
concepts.execution.pipelines.guidance.link: 'función de renderizado del triángulo'
concepts.execution.pipelines.title: 'Estado de la canalización'
concepts.execution.queues.description: '{graphicsQueue} es el punto de partida habitual para un fotograma que combina dibujo, cálculo y copias. Agrupar operaciones dependientes en una cola simplifica su ordenación.'
-concepts.execution.queues.details: 'Las colas permiten enviar cargas de trabajo independientes por separado, aunque no necesariamente corresponden a motores de hardware independientes. Use colas adicionales cuando resulte útil solapar la ejecución. Si una cola utiliza datos producidos por otra, conecte sus envíos mediante una dependencia explícita.'
+concepts.execution.queues.details: 'Las colas adicionales pueden ayudar a solapar cargas de trabajo independientes, aunque no necesariamente corresponden a motores de hardware independientes. Si una cola utiliza datos producidos por otra, conecte sus envíos mediante una dependencia explícita.'
concepts.execution.queues.guidance: 'Dentro de una cola, las operaciones dependientes también pueden necesitar barreras o transiciones de textura para que los accesos posteriores vean las escrituras anteriores. Estas dependencias de memoria son distintas del orden de envío; {link} explica cómo expresarlas.'
concepts.execution.queues.guidance.link: 'Sincronización'
concepts.execution.queues.table.computeQueue.workToRecord: 'Despachos de cálculo y transferencias compatibles, sin pasadas gráficas.'
@@ -41,18 +41,16 @@ concepts.execution.recording.details: 'Tras grabar un fotograma en {commandBuffe
concepts.execution.recording.guidance: 'La grabación construye la secuencia de comandos; {submit} programa su ejecución. La llamada posterior a {wait} bloquea el hilo de la CPU hasta que termina ese envío. Así, el bucle del tutorial resulta fácil de seguir: cada fotograma termina antes de comenzar el siguiente.'
concepts.execution.recording.title: 'Grabación y envío'
concepts.execution.title: 'Modelo de ejecución'
-concepts.platforms.description: 'La presentación puede gestionarla la aplicación o un control de interfaz. Esta elección determina quién obtiene la textura de salida del fotograma, registra y envía los comandos y presenta el resultado. Esa textura de salida se denomina drawable.'
-concepts.platforms.frame.context: 'Grabe los enlaces de canalización y los comandos de dibujo dentro de la pasada y termínela antes de que retorne el manejador. El control envía los comandos y presenta el resultado. El manejador no debe enviar el búfer de comandos ni liberar ninguno de los objetos recibidos. Si cambia la disposición de la textura de salida, restáurela a {colorAttachment} antes de retornar para que el control pueda realizar la transición final.'
-concepts.platforms.frame.description: 'Los controles implementan {iZenithView}. La aplicación asigna {graphicsContext}, actualiza la escena en {updateRequested} y graba en {renderRequested} mediante los {renderEventArgs} recibidos.'
+concepts.platforms.description: 'La presentación puede gestionarla la aplicación o un control de interfaz. Esta elección determina quién obtiene la textura de salida del fotograma, graba y envía los comandos y presenta el resultado. Esa textura de salida se denomina drawable.'
+concepts.platforms.frame.context: 'Grabe los enlaces de canalización y los comandos de dibujo dentro de la pasada y termínela antes de que retorne el manejador. El manejador no debe enviar el búfer de comandos ni liberar ninguno de los objetos recibidos. Si cambia la disposición de la textura de salida, restáurela a {colorAttachment} antes de retornar para que el control pueda realizar la transición final.'
+concepts.platforms.frame.description: 'Los controles implementan {iZenithView}. La aplicación asigna {graphicsContext}, actualiza los datos de la escena en {updateRequested} y graba los comandos en {renderRequested} con los {renderEventArgs} recibidos.'
concepts.platforms.frame.details: 'En cada fotograma, el control obtiene una textura de salida y un búfer de comandos, cambia la disposición de la textura a {colorAttachment} y llama a los manejadores de actualización y renderizado. Después envía el trabajo grabado y presenta la imagen mediante el mecanismo del framework.'
concepts.platforms.frame.guidance: 'Añada {usingZenithNET} al archivo. Para una instancia de {iZenithView} llamada {view}, ya inicializada y con un contexto gráfico asignado, registre este manejador del evento de renderizado para borrar la textura de salida que proporciona el control:'
concepts.platforms.frame.notes: 'La transición inicial utiliza {undefined}, que permite descartar el contenido anterior. Dibuje o borre la imagen completa en cada fotograma. Guarde el renderizado acumulado o en caché en una textura propia de la aplicación y dibújela después sobre la textura de salida del control.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} proporciona el formato de color predeterminado de estas integraciones.'
concepts.platforms.frame.title: 'Renderizado mediante controles de interfaz'
-concepts.platforms.integration.context: 'WinForms, WPF y la integración Windows de WinUI se ejecutan en Windows. Para MAUI, instale la carga de trabajo de la plataforma de destino y registre el controlador con {useZenithView}, como se muestra en {extensionsCs}.'
+concepts.platforms.integration.context: 'WinForms, WPF y la integración de WinUI para Windows se ejecutan en Windows. Para MAUI, instale la carga de trabajo de la plataforma de destino y registre el manejador del control con {useZenithView}, como se muestra en {extensionsCs}.'
concepts.platforms.integration.description: 'La interfaz de eventos es común, pero la presentación depende del framework:'
-concepts.platforms.integration.details: 'Estas implementaciones difieren en cómo llevan la imagen de la GPU a la interfaz. La lectura como mapa de bits copia los píxeles a la memoria de la CPU antes de mostrarlos. La interoperabilidad mediante texturas compartidas evita esa copia, pero aún puede necesitar copias en la GPU y sincronización. Al elegir una integración, considere este mecanismo de presentación además del evento común {renderRequested}.'
-concepts.platforms.integration.guidance: 'Añada mediante NuGet el paquete de integración de su framework de interfaz. Para Avalonia, utilice {avaloniaPackage}.'
+concepts.platforms.integration.details: 'Las integraciones de interfaz presentan las imágenes de la GPU de distintas maneras. La lectura como mapa de bits copia los píxeles a la memoria de la CPU antes de mostrarlos. La interoperabilidad mediante texturas compartidas evita esa copia, aunque puede requerir copias en la GPU y sincronización. Al elegir una integración, considere esta vía de presentación junto con el evento común {renderRequested}.'
concepts.platforms.integration.table.avalonia.integration: 'Avalonia'
concepts.platforms.integration.table.avalonia.presentation: 'Renderiza en una textura y descarga píxeles en un {writeableBitmap}. Consulte {zenithViewCs} y {surfaceCs}.'
concepts.platforms.integration.table.headings.integration: 'Integración'
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: 'Mecanismo de presen
concepts.platforms.integration.table.maui.integration: '.NET MAUI'
concepts.platforms.integration.table.maui.presentation: 'Utiliza superficies nativas en Android, iOS y Mac Catalyst, y composición de texturas compartidas en Windows. Consulte las {link}.'
concepts.platforms.integration.table.maui.presentation.link: 'implementaciones de plataforma'
-concepts.platforms.integration.table.uno.integration: 'Ruta de Uno'
+concepts.platforms.integration.table.uno.integration: 'Uno Platform'
concepts.platforms.integration.table.uno.presentation: 'Descarga píxeles en un {writeableBitmap}. Consulte {zenithViewUnoCs}.'
concepts.platforms.integration.table.winForms.integration: 'WinForms'
concepts.platforms.integration.table.winForms.presentation: 'Crea una cadena de intercambio de Zenith.NET para el {hWND} del control. Consulte {zenithViewCs}.'
@@ -69,23 +67,23 @@ concepts.platforms.integration.table.winUI.presentation: 'Renderiza en una textu
concepts.platforms.integration.table.wpf.integration: 'WPF'
concepts.platforms.integration.table.wpf.presentation: 'Importa una textura compartida de Direct3D 11 y copia su contenido, mediante interoperabilidad con Direct3D, a una superficie que muestra {d3DImage}. Consulte {surfaceCs}.'
concepts.platforms.integration.title: 'Framework y presentación'
-concepts.platforms.lifecycle.context: 'Al crear adjuntos compatibles, utilice {descWidth}, {descHeight}, {descFormat} y {descSampleCount} de la textura de salida que proporciona el evento de renderizado. Esa textura indica las dimensiones reales del destino; no deben deducirse del tamaño de diseño del control ni de la escala de pantalla.'
+concepts.platforms.lifecycle.context: 'Al crear adjuntos compatibles, utilice {descWidth}, {descHeight}, {descFormat} y {descSampleCount} de la textura de salida que proporciona el evento de renderizado. Esa textura indica las dimensiones reales del destino; no deben deducirse del tamaño que ocupa el control en la interfaz ni de la escala de pantalla.'
concepts.platforms.lifecycle.description: 'La cadena de intercambio utiliza el ancho y el alto en píxeles del búfer de fotogramas, que pueden diferir del tamaño lógico de la ventana cuando hay escalado de pantalla. Aplace el renderizado y el redimensionamiento de la cadena mientras alguna dimensión sea cero. Obtenga {swapChainDrawable} en cada fotograma: la cadena de intercambio posee esta textura y puede sustituirla tras presentar o redimensionar.'
concepts.platforms.lifecycle.details: 'Si cambia el tamaño del búfer de fotogramas, espere a que terminen los usos pendientes de las imágenes anteriores en la GPU antes de llamar a {swapChainResize}. Para sustituir el destino nativo de presentación, espere del mismo modo y pase la nueva descripción de superficie y sus identificadores a {swapChainRefresh}. Al cerrar, libere la cadena de intercambio antes de destruir su destino nativo.'
concepts.platforms.lifecycle.guidance: 'Si la aplicación tiene texturas de profundidad o fuera de pantalla que siguen el tamaño de la ventana, vuelva a crearlas cuando cambie ese tamaño y actualice las constantes que contengan sus identificadores. La canalización se puede reutilizar mientras sigan coincidiendo los formatos y el número de muestras de los adjuntos. El {link} muestra esta separación entre las texturas que se redimensionan y la canalización reutilizable.'
concepts.platforms.lifecycle.guidance.link: 'renderizador de cubo giratorio'
concepts.platforms.lifecycle.title: 'Dimensiones y vida útil de la cadena de intercambio'
concepts.platforms.ownership.description: 'La aplicación posee el contexto asignado y sus recursos de renderizado; el control posee sus recursos de presentación. Cuando cambia {graphicsContext} en la vista, el planificador vuelve a crear los recursos del control para el nuevo contexto. Vuelva a crear también las canalizaciones, los búferes y las texturas de la aplicación para ese contexto.'
-concepts.platforms.ownership.details: 'Antes de sustituir recursos de renderizado, detenga la actividad de fotogramas de la vista y espere al trabajo de la GPU que los utiliza. Solo entonces libere los recursos o el contexto anteriores. Al retirar la vista, la aplicación sigue siendo responsable de liberar el contexto que tenía asignado.'
+concepts.platforms.ownership.details: 'Antes de sustituir recursos de renderizado, detenga el bucle de fotogramas de la vista y espere a que termine el trabajo de la GPU que los utiliza. Después, libere los recursos anteriores. Libere el contexto solo cuando cada vista haya liberado sus recursos de presentación asociados a ese contexto y se hayan liberado todos los recursos de la aplicación creados con él.'
concepts.platforms.ownership.guidance: 'El componente compartido {frameSchedulerCs} ejecuta los manejadores de eventos de cada fotograma mediante el distribuidor de la interfaz de la vista. Limite esos manejadores a actualizar la escena y grabar comandos: un trabajo prolongado en la CPU también retrasa la respuesta de la interfaz.'
concepts.platforms.ownership.title: 'Responsabilidades de aplicación y control'
concepts.platforms.surface.description: 'El {link} utiliza Silk.NET para crear la ventana y procesar sus eventos. Zenith.NET recibe los identificadores nativos y las dimensiones mediante una descripción {surface}, con la que crea una {swapChain}. La aplicación sigue siendo responsable de la ventana del sistema operativo.'
concepts.platforms.surface.description.link: 'tutorial del triángulo'
-concepts.platforms.surface.details: 'Los identificadores nativos deben corresponder al backend:'
+concepts.platforms.surface.details: 'Los identificadores nativos de la superficie dependen de la API gráfica y del sistema de ventanas. Algunas combinaciones habituales son:'
concepts.platforms.surface.guidance: 'El programa anfitrión de {appCs} admite Windows, macOS y X11. En Linux, la ventana proporciona identificadores Xlib, por lo que necesita XWayland para ejecutarse en una sesión Wayland. Una aplicación nativa de Wayland proporciona los identificadores de pantalla y superficie mediante {surfaceWayland}.'
concepts.platforms.surface.table.android.backend: 'Vulkan en Android.'
concepts.platforms.surface.table.apple.backend: 'Metal en plataformas Apple.'
-concepts.platforms.surface.table.headings.backend: 'Backend y plataforma'
+concepts.platforms.surface.table.headings.backend: 'API gráfica y plataforma'
concepts.platforms.surface.table.headings.factory: 'Fábrica de superficies'
concepts.platforms.surface.table.headings.handles: 'Identificadores suministrados por el host'
concepts.platforms.surface.table.wayland.backend: 'Vulkan con un host Wayland nativo.'
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'Superficies de presentación nativas'
concepts.platforms.title: 'Integración de plataforma'
concepts.resources.allocation.context: 'Los recursos colocados en un montículo dependen de su almacenamiento durante toda su vida útil. Después de su último uso en la GPU, libere los recursos antes de liberar el montículo.'
concepts.resources.allocation.description: 'Use un {heap} cuando la aplicación necesite gestionar las asignaciones por sí misma. Un montículo proporciona almacenamiento donde se colocan los recursos en desplazamientos explícitos en bytes; la aplicación elige esos desplazamientos y lleva el registro de las regiones ocupadas.'
-concepts.resources.allocation.details: 'Para cada recurso, llame a {contextGetSizeAndAlignment} con la descripción de búfer o textura que se utilizará al crearlo. Reserve el tamaño devuelto en un desplazamiento múltiplo de la alineación indicada, dentro del montículo y sin solapar otra asignación en uso. Las texturas pueden necesitar relleno específico del backend; por eso, el número de píxeles y los bytes por píxel no bastan para calcular el tamaño de la asignación.'
+concepts.resources.allocation.details: 'Para cada recurso, llame a {contextGetSizeAndAlignment} con la descripción de búfer o textura que se utilizará al crearlo. Reserve el tamaño devuelto en un desplazamiento múltiplo de la alineación indicada, dentro del montículo y sin solapar otra asignación en uso. Las texturas pueden necesitar relleno; por eso, el número de píxeles y los bytes por píxel no bastan para calcular el tamaño de la asignación.'
concepts.resources.allocation.guidance: 'La residencia de un búfer colocado en un montículo debe coincidir con la del montículo. Para almacenar texturas, use un montículo exclusivo de la GPU.'
concepts.resources.allocation.title: 'Asignación en montículos'
concepts.resources.bufferUsages.table.constant.role: 'Parámetros de sombreador leídos a través de un enlace de búfer de constantes.'
@@ -146,27 +144,27 @@ concepts.resources.transfers.description: 'Las cargas copian datos de la CPU a u
concepts.resources.transfers.details: 'Antes de llamar a estos métodos, resuelva los accesos en conflicto de otras colas. La espera interna del método abarca su propia transferencia y no establece una dependencia con otra cola. Cuando se copia directamente a través de memoria mapeada, corresponde al llamador esperar a los accesos de la GPU que entren en conflicto.'
concepts.resources.transfers.guidance: 'Para enviar transferencias junto con otro trabajo de la GPU, grábelas con {commandBufferUpload} o {commandBufferDownload}. La memoria de origen de una carga y la de destino de una descarga tienen requisitos de vida útil distintos:'
concepts.resources.transfers.item: 'Durante una llamada de carga, la biblioteca copia los datos de origen a un almacenamiento temporal de transferencia. Después, la GPU lee los datos desde ese almacenamiento, por lo que el puntero de origen de la aplicación solo debe permanecer válido hasta que retorna la llamada.'
-concepts.resources.transfers.notes: 'En las transferencias de texturas, el paso de fila es la distancia en bytes entre filas consecutivas de datos de la CPU; el paso de sección es la distancia entre secciones de profundidad consecutivas. Estos valores permiten copiar los datos entre su organización en la CPU y el almacenamiento de la textura en la GPU. {link} explica por qué terminar la copia en la GPU y entregar los datos al destino de una descarga son pasos distintos.'
-concepts.resources.transfers.notes.link: 'Sincronización'
+concepts.resources.transfers.layouts: 'Las transferencias de texturas grabadas no incluyen transiciones de disposición. Las cargas requieren {copyDst}; las descargas requieren {copySrc}. Grabe las transiciones a estas disposiciones antes de la copia y, después, a la disposición necesaria para el siguiente uso.'
+concepts.resources.transfers.notes: 'En las transferencias de texturas, el paso de fila es la distancia en bytes entre filas consecutivas de datos de la CPU; el paso entre cortes es la distancia entre cortes de profundidad consecutivos. Estos valores permiten copiar los datos entre la memoria de la CPU y el almacenamiento de la textura en la GPU.'
concepts.resources.transfers.table.bufferDownload.transfer: 'Para {cpuReadOnly}, copia directamente desde la memoria mapeada. En los demás casos, envía la descarga a la cola de transferencia y espera a que termine.'
concepts.resources.transfers.table.bufferUpload.transfer: 'Para {cpuWriteOnly}, copia directamente a la memoria mapeada. En los demás casos, envía la carga a la cola de transferencia y espera a que termine.'
concepts.resources.transfers.table.headings.method: 'Método'
concepts.resources.transfers.table.headings.transfer: 'Comportamiento de transferencia'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'Envía la copia y las transiciones de textura a la cola gráfica y espera a que terminen. El subrecurso seleccionado queda en la disposición final solicitada.'
-concepts.resources.transfers.title: 'Transferencias inmediatas y grabadas'
+concepts.resources.transfers.title: 'Transferencias inmediatas y mediante búferes de comandos'
concepts.resources.usages.description: '{bufferUsages} y {textureUsages} son enumeraciones de indicadores que declaran los usos de un recurso. Se asignan a {bufferDescUsages} y {textureDescUsages}, respectivamente. Para varios usos, se combinan los miembros necesarios mediante {value}.'
concepts.resources.usages.title: 'Usos de recursos'
-concepts.resources.views.description: 'Una {bufferView} describe una región de un búfer y cómo se interpretan sus datos. Una {textureView} selecciona un intervalo de subrecursos y un tipo y formato de textura compatibles. Ambas se refieren al almacenamiento existente, con los usos declarados al crearlo. Los intervalos de las vistas describen el acceso, pero no garantizan una comprobación de límites uniforme en los sombreadores de todos los backends.'
+concepts.resources.views.description: 'Una {bufferView} describe una región de un búfer y cómo se interpretan sus datos. Una {textureView} selecciona un intervalo de subrecursos y un tipo y formato de textura compatibles. Ambas se refieren al almacenamiento existente, con los usos declarados al crearlo. Los intervalos de las vistas describen el acceso, pero no garantizan una comprobación de límites uniforme en los sombreadores.'
concepts.resources.views.details: 'El identificador del propio recurso proporciona su vista predeterminada. Cree otra vista para seleccionar una región o una interpretación compatible diferente. Mantenga vivos tanto la vista como el recurso que la respalda hasta que la GPU termine de utilizarlos; un identificador no conserva ninguno de los dos objetos. Si sustituye alguno, actualice las constantes que contengan el {link} anterior.'
concepts.resources.views.details.link: 'identificador de recurso'
concepts.resources.views.title: 'Vistas y recursos subyacentes'
-concepts.shaders.binding.context: 'El ejemplo asigna {inputTextureSampledHandle} a {input} y {outputTextureStorageHandle} a {output}. En Slang, el parámetro de tipo de {descriptorHandle} determina cómo se accede al recurso:'
+concepts.shaders.binding.context: 'El ejemplo de cálculo asigna {inputTextureSampledHandle} a {input} y {outputTextureStorageHandle} a {output}. En Slang, el parámetro de tipo de {descriptorHandle} determina cómo accede el sombreador a cada recurso:'
concepts.shaders.binding.description: '{setConstantBuffer} selecciona un búfer existente y el desplazamiento de byte desde el que la canalización actual lee sus constantes. Cargue los parámetros en ese almacenamiento antes de que los utilice el sombreador. Si un trabajo anterior de la GPU todavía lee esos bytes, espere a que termine antes de actualizarlos.'
concepts.shaders.binding.details: 'Con el búfer de comandos, la canalización de cálculo, el búfer de constantes cargado y el número de grupos de hilos preparados, grabe el despacho en este orden. Seleccione primero la canalización, ya que el enlace del búfer de constantes se aplica a ella:'
-concepts.shaders.binding.guidance: 'Aquí, {commandBuffer} graba un despacho con {computePipeline} y los parámetros almacenados en {constantBuffer}. El búfer necesita el uso {bufferUsagesConstant}, y el desplazamiento 0 selecciona su comienzo. Si varios registros de constantes comparten un búfer, el desplazamiento inicial de cada registro debe cumplir también la alineación de enlace del backend, con independencia de la disposición de sus campos internos.'
-concepts.shaders.binding.notes: '{resourceHandle} contiene dos campos de 32 bits cuya interpretación depende del backend. Sus valores solo son válidos en el contexto donde se creó el recurso.'
-concepts.shaders.binding.reference: 'El recurso y su vista deben conservarse hasta el último acceso del sombreador. Sustituir una textura o vista exige actualizar las constantes con el identificador anterior. Las reglas de propiedad se detallan en {link}.'
+concepts.shaders.binding.guidance: 'El búfer de constantes necesita el uso {bufferUsagesConstant}. Si varios registros de constantes comparten un búfer, el desplazamiento inicial de cada registro debe cumplir la alineación de enlace requerida, con independencia de la disposición de sus campos internos.'
+concepts.shaders.binding.notes: '{resourceHandle} contiene dos campos de 32 bits cuya interpretación depende de la implementación de la API gráfica. Sus valores solo son válidos en el contexto donde se creó el recurso.'
+concepts.shaders.binding.reference: 'Conserve el recurso y cualquier vista utilizada para obtener su identificador hasta que finalice el último acceso del sombreador. Sustituir una textura o vista exige actualizar las constantes que aún contengan el identificador anterior. Las reglas de propiedad se detallan en {link}.'
concepts.shaders.binding.reference.link: 'Administración de recursos'
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'Lectura de elementos estructurados del tipo {t} del sombreador'
concepts.shaders.binding.table.bufferStorageReadWriteHandle.access: 'Lectura y escritura de elementos estructurados del tipo {t} del sombreador'
@@ -176,8 +174,8 @@ concepts.shaders.binding.table.headings.slangFieldType: 'Tipo de campo Slang'
concepts.shaders.binding.table.samplerHandle.access: 'Estado de muestreo de texturas'
concepts.shaders.binding.table.textureSampledHandle.access: 'Lectura de texturas'
concepts.shaders.binding.table.textureStorageHandle.access: 'Lectura y escritura de texturas de almacenamiento'
-concepts.shaders.binding.title: 'Constantes e identificadores de recursos'
-concepts.shaders.compilation.description: '{zenithCompiler} compila un punto de entrada Slang en un {shaderDesc}. {graphicsApi} selecciona DXIL para DirectX 12, una biblioteca Metal para Metal o SPIR-V para Vulkan.'
+concepts.shaders.binding.title: 'Búferes de constantes e identificadores de recursos'
+concepts.shaders.compilation.description: '{zenithCompiler} compila un punto de entrada Slang y devuelve un {shaderDesc}. El {graphicsApi} del contexto selecciona el formato de salida: {dxil} para DirectX 12, {metallib} para Metal o {spirv} para Vulkan.'
concepts.shaders.compilation.details: 'Con un contexto gráfico ya creado y llamado {context}, compile el sombreador del triángulo a partir de la copia situada junto al ejecutable:'
concepts.shaders.compilation.guidance: 'El nombre del punto de entrada {vSMain} debe coincidir con la declaración del archivo de sombreadores. Compile los sombreadores y cree las canalizaciones durante la inicialización; después, reutilice las canalizaciones al renderizar. Una vez creadas, los objetos sombreador se pueden liberar, como muestra {link}.'
concepts.shaders.compilation.guidance.link: 'Primer triángulo'
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: 'Para la entrada de vértices, {inputLayout
concepts.shaders.layout.details: 'Los búferes de constantes contienen parámetros del sombreador, y los búferes estructurados contienen arrays de elementos tipados. Su disposición sigue las declaraciones de Slang, no {inputLayout}. Ajuste los desplazamientos, tamaños de elemento y relleno de C# a la disposición del sombreador compilado. Un tipo no administrado de C# se puede copiar byte a byte, pero su disposición en memoria no tiene por qué coincidir con la del sombreador; un {float3} empaquetado para un vértice puede necesitar otra alineación en un búfer del sombreador.'
concepts.shaders.layout.guidance: 'Los parámetros del sombreador pueden incluir identificadores de recursos además de valores ordinarios. Un identificador se refiere a almacenamiento ya existente, por lo que copiarlo a un búfer de constantes no copia el contenido del recurso.'
concepts.shaders.layout.notes: 'La declaración correspondiente en {computeShaderSlang} es:'
-concepts.shaders.layout.reference: 'Las dos dimensiones ocupan los primeros ocho bytes, seguidas de dos identificadores de ocho bytes cada uno. El ejemplo de C# reserva 256 bytes para el registro completo. El tamaño de otros registros se debe calcular a partir de sus propios campos y requisitos de disposición y alineación.'
+concepts.shaders.layout.reference: 'Los campos de C# ocupan los primeros 24 bytes: ocho para las dimensiones y ocho por identificador. El registro de 256 bytes deja los bytes restantes como relleno. Para otro bloque de parámetros, ajuste los desplazamientos de los campos a la disposición de su sombreador. Si varios registros comparten un búfer, incluya suficiente relleno entre ellos para cumplir la alineación de enlace requerida.'
concepts.shaders.layout.title: 'Disposición de los datos'
concepts.shaders.matrices.description: 'El compilador almacena las matrices por filas contiguas. El {link} sitúa tres valores {matrix4x4} en los desplazamientos 0, 64 y 128. Su {detail} aplica {mulVectorMatrix} en el orden modelo, vista y proyección.'
concepts.shaders.matrices.description.detail: 'sombreador'
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: 'renderizador de cubo giratorio'
concepts.shaders.matrices.details: 'El orden de almacenamiento define la disposición de los elementos de la matriz en memoria; el de multiplicación define la transformación. Las convenciones de C# y Slang deben coincidir.'
concepts.shaders.matrices.title: 'Convenciones matriciales'
concepts.shaders.title: 'Datos de sombreadores y enlace'
-concepts.synchronization.backends.description: 'DirectX 12 y Vulkan codifican las transiciones de textura como cambios de disposición y acceso. En Metal, la implementación de {transition} de Zenith.NET no realiza una operación equivalente. El backend de Metal agrupa los comandos en codificadores de renderizado y cálculo e inserta barreras de visibilidad cuando termina un codificador. Las operaciones dependientes dentro del mismo codificador, como los despachos de cálculo sucesivos, utilizan llamadas explícitas a {barrier}.'
-concepts.synchronization.backends.details: 'En el {link}, iniciar la pasada gráfica termina el codificador de cálculo y hace visible su salida para el trabajo gráfico. Dos despachos de cálculo consecutivos permanecen en el mismo codificador, de modo que necesitan una barrera aunque se grabe una transición de textura entre ellos. Por eso, una secuencia de comandos portable debe contemplar tanto las dependencias de acceso como las disposiciones de textura.'
+concepts.synchronization.backends.description: 'DirectX 12 y Vulkan codifican las transiciones de textura como cambios de disposición y acceso. En la implementación de Metal de Zenith.NET, {transition} no realiza una operación de GPU equivalente. Esta implementación agrupa los comandos en codificadores de renderizado y cálculo e inserta barreras de visibilidad cuando termina un codificador. Las operaciones dependientes dentro del mismo codificador, como los despachos de cálculo sucesivos, requieren llamadas explícitas a {barrier}.'
+concepts.synchronization.backends.details: 'En el {link}, iniciar la pasada gráfica termina el codificador de cálculo y hace visible su salida para el trabajo gráfico. Dos despachos de cálculo consecutivos permanecen en el mismo codificador, de modo que necesitan una barrera aunque se grabe una transición de textura entre ellos.'
concepts.synchronization.backends.details.link: 'ejemplo de cálculo'
-concepts.synchronization.backends.title: 'Comportamiento de los backends'
+concepts.synchronization.backends.title: 'Sincronización según la API gráfica'
concepts.synchronization.barriers.context: 'Elija etapas que incluyan los accesos implicados y que admita la cola. {barrierStagesAll} incluye todas las etapas admitidas; seleccione un conjunto más reducido si la dependencia solo afecta a esas etapas.'
concepts.synchronization.barriers.description: 'Considere dos despachos de cálculo grabados en el mismo búfer de comandos: el primero escribe datos de simulación y el segundo los lee. Coloque una barrera entre ambos para que el segundo vea las escrituras completadas. En un búfer de almacenamiento, esto ordena los accesos sin una transición de disposición de textura:'
concepts.synchronization.barriers.details: 'El primer argumento identifica las etapas que producen los datos; el segundo, las que los consumen. Juntos describen el orden de ejecución y la visibilidad de memoria necesarios entre los dos despachos.'
-concepts.synchronization.barriers.guidance: 'La {link} aplica este patrón entre los pasos de simulación. Cada barrera va después del despacho que produce los datos y antes del que los utiliza.'
+concepts.synchronization.barriers.guidance: 'La {link} aplica este patrón entre los pasos de simulación.'
concepts.synchronization.barriers.guidance.link: 'simulación FluidTank'
concepts.synchronization.barriers.title: 'Barreras de canalización'
concepts.synchronization.dependencies.description: 'Para cada recurso, identifique los accesos que afectan a los mismos datos. Si alguno escribe, conserve el orden necesario entre ellos. Dos lecturas no entran en conflicto, aunque siguen vigentes los requisitos de disposición de textura y presentación. Las actualizaciones de la CPU y la liberación de recursos también deben esperar a que la GPU termine de utilizar el almacenamiento afectado.'
concepts.synchronization.dependencies.details: 'El mecanismo se elige según dónde se ejecutan las operaciones:'
-concepts.synchronization.dependencies.guidance: 'Una carga de trabajo puede necesitar varios mecanismos. Por ejemplo, una textura producida en otra cola necesita una dependencia entre envíos y la disposición adecuada para su siguiente uso. Ninguna de estas operaciones exige bloquear la CPU, salvo que esta necesite acceder a los datos o liberarlos.'
+concepts.synchronization.dependencies.guidance: 'Cuando una cola escribe en una textura que utiliza otra, envíe el trabajo con una dependencia y grabe la transición de disposición necesaria. Ninguno de estos pasos bloquea la CPU. Espere a que termine el trabajo antes de que la CPU acceda a los datos o libere el recurso.'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: 'Llamar a {wait} en el valor de finalización correspondiente.'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'El acceso de la CPU o la liberación de recursos depende de la finalización en la GPU'
concepts.synchronization.dependencies.table.crossQueue.mechanism: 'Pase el {timelineValue} del productor a {submit} del consumidor.'
@@ -225,7 +223,7 @@ concepts.synchronization.dependencies.table.layoutChange.situation: 'Un subrecur
concepts.synchronization.dependencies.table.pipelineStages.mechanism: '{commandBufferBarrier} con las etapas productora y consumidora.'
concepts.synchronization.dependencies.table.pipelineStages.situation: 'Etapas de GPU dependientes en un flujo de comandos'
concepts.synchronization.dependencies.title: 'Dependencias de acceso'
-concepts.synchronization.description: 'La sincronización establece el orden de acceso a los datos compartidos y permite que las operaciones posteriores vean los resultados que necesitan. En una dependencia de escritura a lectura, quien escribe es el productor y quien lee es el consumidor. Las barreras y las transiciones coordinan los accesos de la GPU; las líneas de tiempo conectan envíos y permiten que la CPU espere a que termine el trabajo de la GPU.'
+concepts.synchronization.description: 'La sincronización establece el orden de acceso a los datos compartidos y permite que las operaciones posteriores vean los resultados que necesitan. En una dependencia de escritura a lectura, quien escribe es el productor y quien lee es el consumidor. Las barreras y las transiciones de textura coordinan los accesos de la GPU; las líneas de tiempo conectan envíos y permiten que la CPU espere a que termine el trabajo de la GPU.'
concepts.synchronization.layouts.context: 'Use {undefined} como disposición anterior cuando se pueda descartar el contenido, por ejemplo, en una imagen nueva o en un adjunto que se vaya a borrar por completo. Para conservarlo para una carga, un muestreo o una acumulación, indique la disposición del acceso anterior.'
concepts.synchronization.layouts.description: 'Los indicadores de uso declaran las funciones permitidas de una textura. {textureLayout} describe cómo se accede a un subrecurso, identificado por un nivel de mip y una capa de array, en un punto concreto de la secuencia de comandos. Cuando cambia ese acceso, grabe una transición. En el ejemplo de cálculo, la textura de salida se escribe en disposición {storage} y después se prepara para muestrearla en una pasada gráfica:'
concepts.synchronization.layouts.details: '{outputTexture} se creó con {sampledStorage}, y el subrecurso seleccionado está en {storage}. {default} elige el nivel mip 0 y la capa 0. Los demás niveles y capas no cambian.'
@@ -237,8 +235,8 @@ concepts.synchronization.readback.guidance: 'Consultar {isCompleted} por sí sol
concepts.synchronization.readback.guidance.link: 'Administración de recursos'
concepts.synchronization.readback.title: 'Finalización de la lectura en CPU'
concepts.synchronization.reuse.description: 'El triángulo espera a que termine cada fotograma antes de reutilizar sus datos. Para solapar fotogramas, reserve almacenamiento modificable para cada uno de los que estén en curso y registre cuándo vuelve a estar disponible. Antes de cambiar datos, espere al trabajo de la GPU que todavía acceda a esos bytes; antes de liberar un recurso, espere a todos sus usos pendientes.'
-concepts.synchronization.reuse.details: 'El redimensionamiento y el cierre siguen la misma regla: impedir nuevos usos, esperar a que terminen los existentes y sustituir o liberar los recursos. Respete ese orden antes de llamar a {swapChainResize} o liberar recursos o el contexto. Como el triángulo ya espera en cada fotograma, puede redimensionar entre las llamadas a sus funciones de respuesta.'
-concepts.synchronization.reuse.guidance: '{swapChainPresent} señala un punto de la cola gráfica y espera a él después de la presentación. Por tanto, el triángulo sigue esperando al presentar aunque se elimine la espera explícita del envío. El trabajo independiente de otras colas necesita su propio seguimiento de finalización.'
+concepts.synchronization.reuse.details: 'El redimensionamiento y el cierre siguen la misma regla: impedir nuevos usos, esperar a que terminen los existentes y sustituir o liberar los recursos. Respete ese orden antes de llamar a {swapChainResize} o liberar recursos o el contexto. Como el tutorial espera a que termine cada fotograma, puede cambiar el tamaño entre llamadas a los manejadores.'
+concepts.synchronization.reuse.guidance: '{swapChainPresent} señala un punto de finalización en la cola gráfica y espera a que se alcance después de la presentación. Por tanto, el triángulo sigue esperando al presentar aunque se elimine la espera explícita del envío. El trabajo independiente de otras colas necesita su propio seguimiento de finalización.'
concepts.synchronization.reuse.title: 'Reutilización de recursos'
concepts.synchronization.timelines.context: 'Si la CPU necesita leer el resultado, sobrescribir los datos compartidos o liberar los recursos cuando termine el consumidor, espere a ese envío:'
concepts.synchronization.timelines.description: 'Una línea de tiempo identifica la finalización con valores crecientes. {submit} devuelve un {timelineValue} con la línea y el valor del envío. Los campos numéricos {value} de líneas distintas no se comparan directamente.'
@@ -256,7 +254,7 @@ home.entries.reference.category: 'Referencia'
home.entries.reference.description: 'Consultar tipos, miembros y declaraciones de la API'
home.entries.reference.title: 'Referencia de la API'
home.entries.samples.action: 'Examinar ejemplos'
-home.entries.samples.category: 'Ejemplos'
+home.entries.samples.category: 'Ejemplos de código'
home.entries.samples.description: 'Ejemplos ejecutables de técnicas gráficas y de cálculo'
home.entries.samples.title: 'Ejemplos'
home.entries.title: 'Documentación'
@@ -265,19 +263,19 @@ home.entries.tutorial.category: 'Tutorial'
home.entries.tutorial.description: 'De un proyecto vacío al primer triángulo en pantalla'
home.entries.tutorial.title: 'Primer triángulo'
home.introduction.accent: 'con .NET'
-home.introduction.description: 'Zenith.NET ofrece una API común de gráficos y cálculo para DirectX, Metal y Vulkan'
+home.introduction.description: 'Zenith.NET ofrece una API común de gráficos y cálculo para DirectX 12, Metal 4 y Vulkan 1.4'
home.introduction.title: 'Gráficos multiplataforma{lineBreak}{accent}'
-home.meta.description: 'Desarrollo gráfico y de cálculo multiplataforma en .NET con una API común para DirectX, Metal y Vulkan'
+home.meta.description: 'Desarrollo gráfico y de cálculo multiplataforma en .NET con una API común para DirectX 12, Metal 4 y Vulkan 1.4'
home.scene.description: 'Geometría interactiva en rotación. Arrastre o utilice las flechas para cambiar la vista.'
home.scene.label: 'Visualización geométrica'
home.scene.surface: 'Superficie'
home.scene.wireframe: 'Estructura alámbrica'
-home.title: 'API gráfica para .NET'
+home.title: 'RHI moderna para .NET'
learning.concepts.description: 'Criterios para elegir usos de recursos, describir datos de sombreadores y coordinar la ejecución en la GPU'
learning.concepts.execution.description: 'Grabación, envío y tiempo de vida de los recursos'
learning.concepts.platforms.description: 'Presentación nativa y controles de renderizado'
learning.concepts.resources.description: 'Usos de recursos, ubicación de memoria y vistas'
-learning.concepts.shaders.description: 'Convenciones de disposición y enlace entre C# y Slang'
+learning.concepts.shaders.description: 'Convenciones de disposición de datos y enlace para C# y Slang'
learning.concepts.synchronization.description: 'Dependencias, visibilidad y finalización'
learning.concepts.title: 'Conceptos básicos'
learning.description: 'Empiece por el tutorial del triángulo para crear su primera aplicación. Después, consulte los conceptos de gestión de recursos, datos de sombreadores y sincronización, o elija un ejemplo de la técnica que quiera implementar.'
@@ -289,72 +287,66 @@ learning.meta.description: 'Tutoriales y conceptos del modelo de programación d
learning.title: 'Aprender'
reference.description: 'Referencia de recursos, comandos e integración de plataformas'
reference.entries.commands.description: 'Comandos gráficos, de cálculo y de transferencia'
-reference.entries.commands.label: 'Registrar comandos'
-reference.entries.context.description: 'Creación de recursos GPU para el backend elegido'
+reference.entries.commands.label: 'Grabar comandos'
+reference.entries.context.description: 'Creación de recursos GPU mediante un contexto gráfico'
reference.entries.context.label: 'Empezar aquí'
reference.meta.description: 'Espacios de nombres, tipos y miembros de Zenith.NET'
reference.navigation.core: 'Referencia de la API principal'
reference.title: 'Referencia de la API'
-samples.computeShader.description: 'El ejemplo carga la imagen {assetsTexturesShokoPng}, la convierte a escala de grises en un despacho de cálculo y muestra la textura resultante. La conversión se ejecuta una vez; los fotogramas siguientes muestran el mismo resultado. El renderizador ilustra cómo enlazar texturas para muestreo y escritura, redondear hacia arriba el número de grupos de hilos para cubrir la imagen y comprobar sus límites en el sombreador.'
+samples.computeShader.description: 'Un sombreador de cálculo convierte una imagen en color a escala de grises y muestra cómo procesar imágenes en la GPU.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: 'Sombreador de cálculo'
-samples.cube.description: 'El cubo añade dibujo indexado, matrices de modelo, vista y proyección en un búfer de constantes y prueba de profundidad. Su textura de profundidad y plantilla {d32FloatS8UInt} se recrea al redimensionar.'
+samples.cube.description: 'Un cubo giratorio muestra el uso de geometría indexada, transformaciones 3D y pruebas de profundidad.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: 'Cubo giratorio'
-samples.description: 'Cada ejemplo reúne un renderizador C# y su sombreador Slang en torno a una técnica. La configuración completa y la secuencia de renderizado se explican en {link}.'
-samples.description.link: 'Primer triángulo'
+samples.description: 'Estos ejemplos abarcan el renderizado y el cálculo, desde un único triángulo hasta aplicaciones interactivas y herramientas de diagnóstico.'
samples.execution.description: 'Ejecute el proyecto {link} y elija un ejemplo en el menú de la consola.'
samples.execution.description.link: 'ZenithTutorials'
samples.execution.title: 'Ejecución de ejemplos'
-samples.host.description: '{appCs} inicializa contexto, ventana y cadena de intercambio. En cada fotograma obtiene un búfer, llama al renderizador, envía los comandos y presenta el resultado. {iRendererCs} define actualización, renderizado, redimensionamiento y liberación.'
-samples.host.details: 'Los renderizadores de cálculo y trazado de rayos producen texturas fuera de pantalla. {texturePresenterCs} y {presentTextureSlang} las dibujan en la textura de salida actual; después, el programa anfitrión compartido envía los comandos y presenta el fotograma.'
-samples.host.title: 'Host y presentación'
-samples.indirectDrawing.description: 'El dibujo indirecto representa varias instancias de cubo mediante un búfer de argumentos de dibujo indexado y un búfer estructurado con datos por instancia. La CPU proporciona los argumentos y actualiza las transformaciones.'
+samples.indirectDrawing.description: 'Una cuadrícula de cubos giratorios de distintos colores demuestra el dibujo indirecto a partir de un búfer de argumentos de dibujo.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: 'Dibujo indirecto'
-samples.meshShading.description: 'Un sombreador de tareas descarta las instancias de esferas no visibles y pasa los índices restantes al sombreador de mallas, que genera la geometría. El renderizador comprueba {contextCapabilitiesMeshShadingSupported} antes de crear la canalización.'
+samples.meshShading.description: 'Este ejemplo utiliza sombreadores de tareas y de mallas para renderizar una cuadrícula de esferas de colores y omite las que quedan fuera del campo de visión de la cámara. Requiere soporte de sombreado de mallas.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: 'Sombreado de mallas'
-samples.rayTracing.description: 'El ejemplo construye estructuras de aceleración de nivel inferior y superior para un suelo y esferas procedurales, y realiza consultas de rayos dentro de un sombreador de cálculo. Comprueba {contextCapabilitiesRayTracingSupported} antes de la inicialización.'
+samples.rayTracing.description: 'Este ejemplo utiliza consultas de rayos para renderizar esferas reflectantes y sombras sobre un suelo ajedrezado. Requiere soporte de trazado de rayos.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: 'Trazado de rayos'
samples.title: 'Ejemplos'
-samples.triangle.description: 'El triángulo asocia un búfer de vértices con su disposición de entrada y dibuja tres vértices mediante una canalización gráfica.'
+samples.triangle.description: 'Un triángulo con transiciones suaves entre los colores de sus vértices introduce la canalización gráfica básica.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: 'Tutorial completo'
samples.triangle.title: 'Hola triángulo'
-samples.workloads.description: 'El {link} del repositorio principal contiene aplicaciones de mayor escala que utilizan el código fuente de la biblioteca.'
+samples.workloads.description: 'El {link} del repositorio de Zenith.NET contiene estas aplicaciones y utilidades.'
samples.workloads.description.link: 'directorio Experiments'
-samples.workloads.details: 'Las aplicaciones con ventana usan los mismos caminos de Windows, macOS y Linux/X11. {link} describe los controles Avalonia, WinForms, WPF, WinUI/Uno y MAUI, su ciclo de fotogramas y sus implementaciones.'
-samples.workloads.details.link: 'Integración de plataforma'
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: 'CornellBox'
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Trazado de caminos, reducción de ruido, asignación de tonos, aumento de resolución y controles ImGui. Requiere soporte de trazado de rayos.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Una escena interactiva de una habitación para explorar la iluminación y los reflejos. Requiere soporte de trazado de rayos.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: 'FluidTank'
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Simulación de fluidos por cálculo, dependencias entre etapas de simulación y renderizado de superficies multipasada.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Una simulación de agua en un tanque, con vistas de la superficie y de las partículas.'
samples.workloads.table.headings.example: 'Ejemplo'
-samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Técnicas y requisitos'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Descripción'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: 'InkCanvas'
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'Dibujo con Skia y control de entrada en una ventana nativa. Requiere el backend y la biblioteca nativa de Skia para la plataforma de destino.'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'Un lienzo para dibujar y borrar trazos a mano alzada.'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: 'PlatformDetection'
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Intenta crear un contexto para cada backend e informa de las capacidades del dispositivo. Si un intento falla, lo muestra como no compatible; la causa puede estar en el dispositivo, el controlador o una dependencia de ejecución ausente.'
-samples.workloads.title: 'Aplicaciones de mayor escala'
-tutorial.context.description: 'Un {graphicsContext} conecta la aplicación con la GPU mediante un backend y proporciona los métodos para crear los recursos de renderizado.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Una herramienta de consola que muestra qué API gráficas están disponibles y las capacidades del dispositivo.'
+samples.workloads.title: 'Aplicaciones y utilidades'
+tutorial.context.description: 'Un {graphicsContext} conecta la aplicación con la GPU mediante la API gráfica elegida y proporciona métodos para crear recursos de renderizado.'
tutorial.context.details: 'Inserte la inicialización del contexto {emphasis}:'
tutorial.context.details.emphasis: 'después de las directivas using, antes de {iWindowWindow}'
-tutorial.context.guidance: 'Cada rama selecciona el backend de la plataforma y solicita la validación. Los mensajes de {validationMessage} aparecen en la consola.'
+tutorial.context.guidance: 'Cada rama solicita la validación para su API gráfica. El manejador imprime los diagnósticos de {validationMessage} cuando la implementación los proporciona.'
tutorial.context.imports: 'Añada las siguientes directivas using al principio de {programCs}:'
tutorial.context.title: 'Contexto gráfico'
tutorial.description: 'Este tutorial parte de un proyecto de consola .NET vacío para crear una aplicación que abre una ventana y dibuja un triángulo de colores.'
tutorial.details: 'El tutorial tiene tres puntos de comprobación: una ventana vacía, un fondo de color uniforme y el triángulo de colores. Ejecute la aplicación en cada uno antes de continuar con el siguiente paso.'
tutorial.draw.context: 'Los argumentos para {draw} son:'
tutorial.draw.description: 'En {windowRender}, sustituya {addTheTriangleDrawCommandsHereLater} por estos comandos entre {beginRenderPass} y {endRenderPass}:'
-tutorial.draw.details: '{setPipeline} selecciona sombreadores y estado. Debe preceder al enlace de vértices porque el backend lo interpreta según la disposición de entrada de la canalización.'
+tutorial.draw.details: '{setPipeline} selecciona los sombreadores y el estado de renderizado. Enlace la canalización antes del búfer de vértices para que su disposición de entrada determine cómo se leen los datos de los vértices.'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} enlaza los datos de vértices ya cargados desde el desplazamiento de byte 0 a la ranura de entrada 0, que corresponde a la única entrada de {inputLayouts}.'
-tutorial.draw.notes: 'Estas llamadas graban los comandos de dibujo. La llamada existente a {submitWait} los envía y espera a que termine la GPU; después, {present} solicita que se muestre la imagen completada. Conserve el borrado al inicio de la pasada para que la zona exterior al triángulo tenga un color de fondo definido.'
+tutorial.draw.notes: 'Conserve el borrado al inicio de la pasada para que la zona exterior al triángulo tenga un color de fondo definido.'
tutorial.draw.table.firstInstance.meaning: 'Comenzar la numeración de instancias en cero.'
tutorial.draw.table.firstVertex.meaning: 'Comenzar con el primer vértice en el búfer.'
tutorial.draw.table.headings.argument: 'Argumento'
@@ -370,40 +362,39 @@ tutorial.execution.title: 'Ejecución de la aplicación'
tutorial.frame.commands.context: 'Después de {endRenderPass}, la segunda transición prepara la textura de salida para su presentación. {submit} termina la grabación y envía el búfer de comandos; {wait} bloquea el hilo hasta que termina ese envío. A continuación, {present} solicita que se muestre la imagen renderizada.'
tutorial.frame.commands.description: 'Una pasada de renderizado agrupa las operaciones de dibujo que escriben en los mismos adjuntos. En esta pasada, la textura de salida de la cadena de intercambio recibe el color. {colorAttachmentClear} indica cómo inicializar ese adjunto con un color RGBA y conservar su contenido al terminar la pasada. {beginRenderPass} graba el inicio de la pasada con estos ajustes.'
tutorial.frame.commands.details: 'La colección contiene un adjunto de color. {null} indica que la pasada no tiene adjunto de profundidad y plantilla.'
-tutorial.frame.commands.guidance: '{beginRenderPass} configura el área de visualización y el rectángulo de recorte para cubrir todo el adjunto. El área de visualización transforma las coordenadas de renderizado en posiciones de píxeles; el rectángulo de recorte limita dónde se puede escribir.'
+tutorial.frame.commands.guidance: '{beginRenderPass} configura el área de visualización y el rectángulo de recorte para cubrir todo el adjunto. El área de visualización transforma las coordenadas de renderizado en posiciones de píxeles; el rectángulo de recorte limita los píxeles a los que pueden afectar las operaciones de dibujo.'
tutorial.frame.commands.title: 'Borrado, envío y presentación'
-tutorial.frame.description: 'Comience por rellenar la ventana con un color de fondo. Esta operación se llama borrado. Cuando el fondo aparece, la superficie, el envío y la presentación ya funcionan juntos y se pueden añadir los vértices y los sombreadores del triángulo.'
-tutorial.frame.details: 'Silk.NET invoca el callback cuando corresponde producir un fotograma. El argumento de tiempo transcurrido no se usa y se denomina {value}. Registre el callback {emphasis}:'
+tutorial.frame.description: 'Comience por rellenar la ventana con un color uniforme, una operación llamada borrado. Si aparece el color, funcionan el envío de comandos y la presentación. Después añada los vértices y los sombreadores del triángulo.'
+tutorial.frame.details: 'Silk.NET invoca el callback de renderizado cuando corresponde producir un fotograma. Registre el callback {emphasis}:'
tutorial.frame.details.emphasis: 'antes de {windowRun}'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} devuelve un búfer listo para grabar. La grabación describe trabajo GPU; la ejecución comienza después del envío.'
+tutorial.frame.target.description: 'Una cola de comandos recibe el trabajo grabado para ejecutarlo en la GPU. {graphicsQueueCommandBuffer} devuelve un búfer de comandos de la cola gráfica con la grabación ya iniciada. Los comandos grabados definen el trabajo de la GPU; la ejecución comienza solo después del envío.'
tutorial.frame.target.details: 'La disposición de una textura describe el acceso que necesita una operación. La primera llamada a {transition} prepara la textura de salida para usarla como adjunto de color. Aquí, {default} selecciona el nivel de mip 0 y la capa 0 del array, es decir, la imagen base de la textura. Como esta pasada borra toda la imagen, {undefined} permite descartar su contenido anterior.'
tutorial.frame.target.guidance: 'Obtenga la textura de salida en cada fotograma, ya que la presentación puede seleccionar una imagen distinta.'
-tutorial.frame.target.title: 'Preparación de la salida'
+tutorial.frame.target.title: 'Preparación de la textura de salida'
tutorial.frame.title: 'Primer fotograma'
tutorial.geometry.data.description: 'Añada el array de vértices {emphasis}. Mantenga también las siguientes inicializaciones de recursos antes de este callback, en el orden indicado.'
tutorial.geometry.data.description.emphasis: 'antes de {windowRender}'
-tutorial.geometry.data.details: 'Cada entrada construye un {vertex}; las dos expresiones {new} internas aportan posición {vector3} y color {vector4}. Las posiciones forman los vértices superior, inferior derecho e inferior izquierdo. El sombreador añade {w} como cuarta coordenada. Con w = 1, x e y son coordenadas normalizadas del dispositivo: -1 y +1 delimitan la imagen y 0 marca el centro, independientemente de los píxeles.'
+tutorial.geometry.data.details: 'Las tres posiciones forman los vértices superior, inferior derecho e inferior izquierdo. En este ejemplo, x e y abarcan el intervalo de -1 a +1 en la imagen: 0 es el centro, el sentido positivo de x apunta a la derecha y el de y, hacia arriba.'
tutorial.geometry.data.guidance: 'Cada color tiene componentes rojo, verde, azul y alfa, con alfa igual a 1. Los tres vértices tienen z = 0 y están en el mismo plano.'
tutorial.geometry.data.title: 'Posiciones y colores'
tutorial.geometry.description: 'Cada uno de los tres vértices tiene una posición y un color. La GPU determina la forma del triángulo a partir de las posiciones e interpola los colores por su superficie.'
tutorial.geometry.format.description: 'Añada la declaración del vértice {emphasis}:'
tutorial.geometry.format.description.emphasis: 'al final de {programCs}, después de las instrucciones de limpieza'
-tutorial.geometry.format.details: '{file} limita el tipo a {programCs}, y {layoutKindSequential} mantiene los campos en su orden de declaración. {position} contiene tres valores de coma flotante de 32 bits y comienza en el desplazamiento de byte 0; {color} contiene cuatro y comienza en el desplazamiento de byte 12. Cada vértice ocupa, por tanto, 28 bytes. La disposición de entrada describirá esta organización para que la GPU lea los campos correctamente.'
+tutorial.geometry.format.details: '{layoutKindSequential} mantiene los campos en su orden de declaración. {position} contiene tres valores de coma flotante de 32 bits y comienza en el desplazamiento de byte 0; {color} contiene cuatro y comienza en el desplazamiento de byte 12. Cada vértice ocupa, por tanto, 28 bytes. La disposición de entrada describirá esta organización para que la GPU lea los campos correctamente.'
tutorial.geometry.format.imports: 'Añada estas directivas using al principio de {programCs} para utilizar los tipos vectoriales y el atributo que define la disposición de la estructura:'
tutorial.geometry.format.title: 'Representación del vértice'
tutorial.geometry.title: 'Datos de vértices'
tutorial.geometry.upload.context: '{fixed} impide que el recolector de basura mueva el array mientras se usa su dirección. En este búfer escribible por la CPU, {upload} mapea la memoria, copia los bytes y deshace el mapeo antes de retornar. El array solo debe permanecer anclado durante la llamada. Cargue los vértices una vez durante la inicialización y conserve el búfer hasta que termine el renderizado.'
tutorial.geometry.upload.description: 'Guarde los vértices en un {buffer} para que la GPU pueda leerlos al dibujar. Añada la asignación y la carga de datos justo después del array:'
-tutorial.geometry.upload.details: '{sizeofVertexVerticesLength} equivale a tres vértices de 28 bytes, 84 bytes en total. {bufferUsagesVertex} declara acceso de entrada, y {cpuWriteOnly} permite inicialización directa por CPU. El paso del descriptor registra el tamaño del elemento; la disposición posterior define cada atributo.'
+tutorial.geometry.upload.details: '{sizeofVertexVerticesLength} equivale a tres vértices de 28 bytes, 84 bytes en total. {bufferUsagesVertex} declara el uso como entrada de vértices, mientras que {cpuWriteOnly} permite la inicialización directa desde la CPU. El paso del descriptor indica el tamaño de cada elemento; la disposición de entrada definida más adelante determina cómo se interpreta cada atributo al leer los vértices.'
tutorial.geometry.upload.guidance: 'La asignación no inicializa el contenido del búfer. {upload} copia el array al desplazamiento de destino 0 utilizando el puntero de origen y el número de bytes de la descripción de datos.'
tutorial.geometry.upload.imports: 'En {programCs}, añada {bufferAlias} a las directivas using para distinguir el tipo de búfer de Zenith.NET de {systemBuffer}.'
-tutorial.geometry.upload.notes: 'Coloque {vertexBufferDispose} justo antes de {swapChainDispose} al final de {programCs}. {link} trata el almacenamiento exclusivo de GPU y las cargas para geometrías mayores.'
-tutorial.geometry.upload.notes.link: 'Administración de recursos'
+tutorial.geometry.upload.notes: 'En el código de limpieza al final de {programCs}, coloque {vertexBufferDispose} justo antes de {swapChainDispose}.'
tutorial.geometry.upload.title: 'Asignación y carga del búfer'
tutorial.input.description: 'La GPU necesita saber dónde se guardan los atributos de cada vértice, como la posición y el color. La disposición de entrada indica su formato y desplazamiento, además del paso: la distancia en bytes hasta el siguiente vértice. Añada este código después de crear los sombreadores:'
tutorial.input.details: '{inputLayoutAdd} sitúa cada atributo a continuación del anterior y suma su tamaño al paso entre vértices. Calcula los desplazamientos a partir de los formatos indicados, sin inspeccionar la estructura de C#. Para estos dos campos, la disposición resultante es:'
tutorial.input.guidance: 'El valor predeterminado de {semanticIndex} es cero, que corresponde a {pOSITION0} y {cOLOR0} en el sombreador. La posición y el color se almacenan juntos en un búfer de vértices, por lo que la canalización utiliza una sola disposición de entrada en la ranura 0. Si cambia el orden de los campos o el relleno de la estructura de C#, ajuste también esta disposición.'
-tutorial.input.table.headings.byteOffset: 'Desplazamiento de bytes'
+tutorial.input.table.headings.byteOffset: 'Desplazamiento en bytes'
tutorial.input.table.headings.cField: 'Campo de C#'
tutorial.input.table.headings.format: 'Formato'
tutorial.input.table.headings.shaderInput: 'Entrada del sombreador'
@@ -413,43 +404,38 @@ tutorial.input.table.nextVertex.shaderInput: 'Siguiente registro de entrada'
tutorial.input.table.vertexColor.format: '{float4} (16 bytes)'
tutorial.input.table.vertexPosition.format: '{float3} (12 bytes)'
tutorial.input.title: 'Disposición de entrada de vértices'
-tutorial.lifecycle.description: 'Cada fotograma sigue esta secuencia:'
-tutorial.lifecycle.details: 'Al cerrar la ventana, {run} retorna y la ejecución continúa en el código de limpieza. Como cada fotograma ya ha esperado a que terminen sus comandos, los recursos que utilizaban se pueden liberar. El bloque completo de limpieza después de {windowRun} es:'
+tutorial.lifecycle.description: 'En cada fotograma, la aplicación obtiene la textura de salida actual, la pasa a la disposición de renderizado, la borra y dibuja el triángulo. Después la pasa a la disposición de presentación, envía los comandos, espera a que terminen y presenta la imagen.'
+tutorial.lifecycle.details: 'Al cerrar la ventana, {run} retorna y la ejecución continúa en el código de limpieza. Como la función de renderizado ya ha esperado a que terminen todos los fotogramas enviados, los recursos utilizados por sus comandos se pueden liberar. El bloque completo de limpieza después de {windowRun} es:'
tutorial.lifecycle.guidance: 'Libere la cadena de intercambio antes de destruir su ventana nativa y el contexto después de sus recursos. La cola recicla los búferes de comandos enviados, y la cadena de intercambio gestiona la textura de salida; ninguno necesita una llamada independiente a {dispose}.'
-tutorial.lifecycle.title: 'Ciclo del fotograma y limpieza'
tutorial.pipeline.behavior: 'Tras la disposición de entrada, cree la canalización:'
tutorial.pipeline.context: '{cullNone} desactiva el descarte de caras, de modo que el triángulo se dibuja tanto si sus vértices aparecen en sentido horario como antihorario.'
tutorial.pipeline.description: 'Una {graphicsPipeline} reúne la disposición de los vértices, los dos sombreadores y los ajustes para ensamblar primitivas y escribir en los adjuntos.'
-tutorial.pipeline.details: 'Los sombreadores procesan vértices y fragmentos. Los demás ajustes de la canalización controlan el ensamblado de primitivas, el descarte de caras, la prueba de profundidad y la mezcla de colores:'
-tutorial.pipeline.guidance: 'El formato debe coincidir con el adjunto de la pasada, por lo que procede de {swapChainDescFormat}. {count1} especifica una muestra por píxel.'
+tutorial.pipeline.guidance: 'El formato de color de la canalización debe coincidir con el adjunto de la pasada, por lo que se toma de {swapChainDescFormat}. {count1} especifica una muestra por píxel.'
tutorial.pipeline.item: '{triangleList} ensambla cada grupo de tres vértices consecutivos en un triángulo.'
-tutorial.pipeline.notes: '{depthNone} desactiva pruebas y escrituras de profundidad, de acuerdo con la ausencia de ese adjunto.'
+tutorial.pipeline.notes: '{depthNone} desactiva las pruebas y escrituras de profundidad, de acuerdo con la ausencia de un adjunto de profundidad.'
tutorial.pipeline.reference: '{opaque} desactiva la mezcla. El color del fragmento sustituye así el fondo dentro del triángulo.'
tutorial.pipeline.title: 'Canalización gráfica'
tutorial.pipeline.usage: 'Los objetos de sombreador pueden liberarse tras crear la canalización. Mantenga la canalización durante el renderizado y añada {pipelineDispose} antes de {vertexBufferDispose} en la limpieza.'
tutorial.presentation.title: 'Contexto gráfico y presentación'
-tutorial.project.context: 'Active {emphasis} ({allowUnsafeBlocks}) en la configuración de compilación. Las llamadas nativas de ventana y la carga de vértices necesitan código no seguro.'
+tutorial.project.context: 'Active {emphasis} ({allowUnsafeBlocks}) en la configuración de compilación. Las llamadas nativas de la clase auxiliar de la ventana y la carga de vértices necesitan código no seguro.'
tutorial.project.context.emphasis: 'Permitir código no seguro'
tutorial.project.description: 'Cree un proyecto de consola C# llamado {firstTriangle} que tenga como destino .NET 10.'
tutorial.project.details: 'Añada los siguientes paquetes NuGet al proyecto:'
-tutorial.project.guidance: '{zenithNET} aporta la API común y los tres paquetes de backend sus implementaciones. {zenithNETCompiler} compila los sombreadores Slang que se presentan a continuación. Silk.NET crea la ventana y procesa eventos.'
+tutorial.project.guidance: '{zenithNET} proporciona la API compartida de gráficos y cálculo; los tres paquetes específicos de cada API la implementan. {zenithNETCompiler} compila sombreadores Slang para la API elegida.'
tutorial.project.title: 'Configuración del proyecto'
-tutorial.requirements.context: 'El {link} y su {detail} proporcionan las implementaciones de referencia del tutorial.'
-tutorial.requirements.context.detail: 'host compartido'
-tutorial.requirements.context.link: 'ejemplo Hola triángulo'
-tutorial.requirements.description: 'Necesita el {emphasis} y conocimientos básicos de C#. La aplicación tiene {net10} como framework de destino. La GPU y el controlador deben admitir el backend elegido para su plataforma:'
+tutorial.requirements.description: 'Necesita el {emphasis} y conocimientos básicos de C#. La GPU y el controlador deben admitir estas capacidades gráficas según la plataforma:'
tutorial.requirements.description.emphasis: 'SDK de .NET 10'
-tutorial.requirements.guidance: 'Zenith.NET renderiza en una superficie nativa proporcionada por la aplicación. Silk.NET.Windowing crea la ventana y procesa eventos. En macOS se utiliza una capa Metal, representada por {cAMetalLayerCs}, que el código auxiliar conecta a la ventana.'
-tutorial.requirements.table.headings.graphicsBackend: 'Backend gráfico'
+tutorial.requirements.guidance: 'Zenith.NET renderiza en una superficie nativa proporcionada por la aplicación. Silk.NET.Windowing crea la ventana y procesa sus eventos.'
+tutorial.requirements.table.headings.graphicsBackend: 'Capacidades gráficas'
tutorial.requirements.table.headings.platform: 'Plataforma'
-tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4'
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 con VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux (X11 o XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: 'Metal 4'
tutorial.requirements.table.macOS.platform: 'macOS'
-tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12'
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 con Shader Model 6.6'
tutorial.requirements.table.windows.platform: 'Windows'
tutorial.requirements.title: 'Requisitos previos'
-tutorial.resize.context: 'Compile y ejecute la aplicación de nuevo. El fondo debe seguir ocupando toda la ventana al cambiar su tamaño: cada nueva pasada ajusta el área de visualización y el rectángulo de recorte a las dimensiones del adjunto. Conserve la función de renderizado; el triángulo se dibujará dentro de esta misma pasada.'
+tutorial.resize.context: 'Compile y ejecute la aplicación de nuevo. El fondo debe seguir ocupando toda la ventana al cambiar su tamaño. Conserve la función de renderizado; el triángulo se dibujará dentro de esta misma pasada.'
tutorial.resize.description: 'La cadena de intercambio debe adaptarse a los cambios de tamaño del búfer de fotogramas. Registre una función para {framebufferResize} después de la función de renderizado y antes de {windowRun}:'
tutorial.resize.details: 'Responda a los {link}, que se miden en píxeles, en lugar de a los cambios de tamaño lógico de la ventana. Si al minimizar la ventana alguna dimensión pasa a ser cero, la función de redimensionamiento mantiene la cadena de intercambio tal como está. La función de renderizado también retorna mientras alguna dimensión sea cero, de modo que el renderizado se reanuda cuando el búfer de fotogramas vuelve a tener un tamaño válido.'
tutorial.resize.details.link: 'cambios de tamaño del búfer de fotogramas'
@@ -465,47 +451,29 @@ tutorial.shaders.compilation.guidance: '{zenithCompiler} compila el código fuen
tutorial.shaders.compilation.title: 'Compilación de sombreadores'
tutorial.shaders.context: '{fSInput} conecta las dos etapas del sombreador. El sombreador de vértices escribe en {sVPOSITION} una posición en el espacio de recorte, que la GPU utiliza para determinar qué parte del triángulo es visible. El campo {cOLOR0} transporta el color del vértice, que se interpola sobre el triángulo antes de llegar al sombreador de fragmentos. Su tipo y su semántica deben coincidir en ambas etapas.'
tutorial.shaders.description: 'Los sombreadores son programas que se ejecutan en la GPU. El sombreador de vértices determina la posición de cada vértice, y el sombreador de fragmentos determina el color en cada posición cubierta de la imagen. Ambos se escribirán en un mismo archivo Slang, con un punto de entrada propio para cada etapa: la función por la que comienza su ejecución.'
-tutorial.shaders.details: 'Cree {triangleSlang} con estas estructuras de entrada y salida:'
+tutorial.shaders.details: 'Cree {triangleSlang} en la raíz del proyecto con estas estructuras de entrada y salida:'
tutorial.shaders.fragment.description: 'Añada el punto de entrada de fragmentos al mismo archivo:'
tutorial.shaders.fragment.details: 'La rasterización determina qué zonas de la imagen cubre el triángulo y genera fragmentos en esas posiciones. Cada fragmento recibe un color interpolado a partir de los colores de los tres vértices. {fSMain} devuelve ese color, y {sVTARGET} dirige el resultado al primer adjunto de color.'
tutorial.shaders.fragment.title: 'Sombreado de fragmentos'
tutorial.shaders.guidance: '{vSInput} define las entradas del sombreador de vértices. {pOSITION0} y {cOLOR0} identifican atributos por semántica; los nombres C# no establecen esa correspondencia.'
tutorial.shaders.title: 'Etapas de sombreado'
tutorial.shaders.vertex.description: 'Añada el punto de entrada de vértices a {triangleSlang}:'
-tutorial.shaders.vertex.details: 'La GPU invoca este punto para cada vértice, incorpora la coordenada homogénea {w} y transmite el color. La posición se divide después por w. Aquí vale 1, por lo que x, y y z no cambian y se interpretan como coordenadas normalizadas del dispositivo.'
+tutorial.shaders.vertex.details: 'La GPU ejecuta esta función para cada vértice de entrada. La función añade un cuarto componente a la posición, {w}, y transmite el color. Tras procesar los vértices, la GPU divide x, y y z entre w para obtener las coordenadas normalizadas del dispositivo. Como w vale 1, estos valores no cambian.'
tutorial.shaders.vertex.title: 'Sombreado de vértices'
tutorial.surface.description: 'Defina el destino de presentación nativo {emphasis}:'
tutorial.surface.description.emphasis: 'después de {windowCenter} y antes de {windowRun}'
tutorial.surface.details: 'El búfer de fotogramas es la imagen de la ventana en píxeles. {surface} describe el destino nativo de presentación y sus dimensiones; {framebufferSize} proporciona el tamaño en píxeles. Con el escalado de pantalla, este puede diferir del tamaño lógico de la ventana.'
-tutorial.surface.guidance: 'La superficie proporciona los identificadores nativos del backend: una ventana Win32 en Windows, una pantalla y una ventana X11 en Linux o la capa Metal conectada en macOS.'
+tutorial.surface.guidance: 'La descripción de la superficie contiene los identificadores nativos que requiere la API gráfica: una ventana Win32 en Windows, una pantalla y una ventana X11 en Linux o la capa Metal asociada en macOS.'
tutorial.surface.title: 'Superficie nativa'
-tutorial.swapChain.context: 'La cadena depende del contexto y de la ventana. Sustituya {windowDispose} al final de {programCs} por este orden de liberación:'
-tutorial.swapChain.description: 'Cree la cadena inmediatamente después de describir la superficie:'
-tutorial.swapChain.details: 'La {swapChain} gestiona las imágenes presentadas. {drawable} suministra la actual como {texture}, el recurso de imagen de la API. Tras renderizar, {present} solicita mostrarla y avanza a la siguiente.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} almacena cuatro canales de 8 bits en orden azul, verde, rojo y alfa. {uNorm} hace corresponder 0–255 con 0–1. La salida sigue siendo RGBA lógico; el formato define su almacenamiento. La canalización usa {swapChainDescFormat} para coincidir con el adjunto.'
+tutorial.swapChain.context: 'La cadena de intercambio depende del contexto y de la ventana. Sustituya {windowDispose} al final de {programCs} por este orden de liberación:'
+tutorial.swapChain.description: 'Cree la cadena de intercambio inmediatamente después de la descripción de la superficie:'
+tutorial.swapChain.details: 'La {swapChain} gestiona las imágenes presentadas por la ventana. {drawable} suministra la imagen actual como {texture}, el recurso de imagen de la API. Tras renderizar, {present} solicita que se muestre esa imagen y avanza a la siguiente textura de salida.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} almacena cuatro canales de 8 bits en orden azul, verde, rojo y alfa. {uNorm} hace corresponder los valores enteros de 0–255 con valores de 0–1. La salida del sombreador sigue siendo un valor RGBA lógico; el formato especifica su representación en memoria.'
tutorial.swapChain.title: 'Cadena de intercambio'
tutorial.title: 'Primer triángulo'
-tutorial.troubleshooting.description: 'Utilice los diagnósticos de consola y los tres puntos de control para localizar el fallo:'
-tutorial.troubleshooting.details: 'El {link} y el {detail} permiten contrastar datos, disposición y dibujo. El ejemplo separa ventana y envío en un host común; el tutorial mantiene el flujo en {programCs}. {context} introduce dibujo indexado, transformaciones y profundidad.'
-tutorial.troubleshooting.details.context: 'Cubo giratorio'
-tutorial.troubleshooting.details.detail: 'sombreador Slang'
-tutorial.troubleshooting.details.link: 'renderizador de ejemplo'
-tutorial.troubleshooting.table.backend.check: 'Compruebe que el backend seleccionado sea compatible con el dispositivo y el controlador de gráficos instalado.'
-tutorial.troubleshooting.table.backend.symptom: 'Falla la creación del backend'
-tutorial.troubleshooting.table.drawing.check: 'Compruebe el tamaño de la carga, la disposición de entrada, la selección de la canalización y la ubicación de los comandos de dibujo dentro de la pasada de renderizado.'
-tutorial.troubleshooting.table.drawing.symptom: 'Aparece el fondo pero no el triángulo'
-tutorial.troubleshooting.table.headings.check: 'Comprobación'
-tutorial.troubleshooting.table.headings.symptom: 'Síntoma'
-tutorial.troubleshooting.table.input.check: 'Compruebe el paso de 28 bytes y los desplazamientos de posición/color de 0 y 12.'
-tutorial.troubleshooting.table.input.symptom: 'Las posiciones o colores de los vértices están dañados'
-tutorial.troubleshooting.table.shaders.check: 'Compruebe el archivo {triangleSlang} copiado, la ortografía del punto de entrada y el diagnóstico notificado por el compilador.'
-tutorial.troubleshooting.table.shaders.symptom: 'El fondo se muestra, pero falla la carga de los sombreadores'
-tutorial.troubleshooting.table.window.check: 'Confirme que el proyecto .NET se compila y que el paso de solo ventana se ejecuta en una sesión de escritorio. En Linux, compruebe que X11 o XWayland estén disponibles.'
-tutorial.troubleshooting.table.window.symptom: 'No se abre ninguna ventana'
-tutorial.troubleshooting.title: 'Diagnóstico de problemas'
tutorial.window.description: 'Descargue {cocoaHelperCs} en el directorio del proyecto. Esta clase auxiliar conecta la capa Metal a la ventana de macOS.'
-tutorial.window.details: 'Sustituya el contenido generado de {programCs} por el código siguiente. Usa instrucciones de nivel superior que se ejecutan en orden, sin un método {main} explícito. Las siguientes secciones indicarán dónde añadir cada fragmento:'
-tutorial.window.guidance: '{graphicsAPINone} deja la creación del contexto gráfico a Zenith.NET. {initialize} crea la ventana nativa y permite acceder a los identificadores del sistema de ventanas. {center} la coloca en el centro de la pantalla. {run} procesa los eventos hasta que se cierra; después se ejecuta {dispose} para liberarla.'
+tutorial.window.details: 'Sustituya el contenido de {programCs} por el código siguiente:'
+tutorial.window.guidance: '{graphicsAPINone} impide que Silk.NET cree su propio contexto gráfico para la ventana; la aplicación creará después un contexto de Zenith.NET. {initialize} crea la ventana nativa y permite acceder a los identificadores del sistema de ventanas. {center} la coloca en el centro de la pantalla. {run} procesa los eventos hasta que se cierra; después, {dispose} libera la ventana.'
tutorial.window.notes: 'Compile y ejecute la aplicación. Compruebe que puede abrir, mover, redimensionar y cerrar la ventana. Su contenido aún no está definido porque no se han enviado comandos de renderizado. Cierre la ventana antes de continuar.'
tutorial.window.title: 'Creación de la ventana'
ui.action.copy: 'Copiar'
@@ -525,12 +493,12 @@ ui.api.noNamespaceTypes: 'No hay tipos en este espacio de nombres.'
ui.api.noTypes: 'No hay tipos coincidentes.'
ui.api.types: 'Tipos'
ui.content.reference: 'Referencia'
-ui.content.source: 'Código fuente'
+ui.content.examples: 'Ejemplos de código'
ui.content.tutorial: 'Tutorial'
ui.contents.close: 'Cerrar el índice'
ui.contents.open: 'Abrir el índice'
ui.contents.title: 'Índice'
-ui.footer.caption: 'API gráfica para .NET'
+ui.footer.caption: 'RHI moderna para .NET'
ui.footer.label: 'Pie de página'
ui.language.label: 'Idioma'
ui.language.unavailable: 'No traducido'
@@ -562,7 +530,6 @@ ui.reference.exceptions: 'Excepciones'
ui.reference.extensionMethods: 'Métodos de extensión'
ui.reference.fields: 'Campos'
ui.reference.implementations: 'Implementaciones explícitas de interfaz'
-ui.reference.implements: 'Implementa'
ui.reference.inheritance: 'Herencia'
ui.reference.inheritedMembers: 'Miembros heredados'
ui.reference.interfaces: 'Interfaces'
@@ -576,7 +543,7 @@ ui.reference.properties: 'Propiedades'
ui.reference.related: 'Vea también'
ui.reference.relationships: 'Herencia y metadatos'
ui.reference.remarks: 'Comentarios'
-ui.reference.returns: 'Devuelve'
+ui.reference.returns: 'Valor devuelto'
ui.reference.structs: 'Estructuras'
ui.reference.typeParameters: 'Parámetros de tipo'
ui.reference.value: 'Valor'
diff --git a/documents/locales/es-ES/translation.md b/documents/locales/es-ES/translation.md
index ef2e35c6..4ac608fa 100644
--- a/documents/locales/es-ES/translation.md
+++ b/documents/locales/es-ES/translation.md
@@ -74,6 +74,8 @@ Antes de entregar, compruebe las claves y los marcadores. Revise la página de i
| command queue | cola de comandos |
| drawable | textura de salida del fotograma actual; conservar `Drawable`, sin asumir que sea una imagen de la cadena de intercambio |
| graphics context | contexto gráfico |
+| graphics API | API gráfica; DirectX 12, Metal 4 o Vulkan 1.4 |
+| implementation | implementación de la API gráfica; para diferencias técnicas entre implementaciones |
| pipeline | canalización |
| readback | lectura de datos desde la GPU |
| render pass | pasada de renderizado |
diff --git a/documents/locales/fr-FR/strings.yml b/documents/locales/fr-FR/strings.yml
index 8e1a4d1e..32eeccc2 100644
--- a/documents/locales/fr-FR/strings.yml
+++ b/documents/locales/fr-FR/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: 'Un {graphicsContext} relie l’application à un périphérique GPU par un backend donné et fournit ses files graphiques, de calcul et de transfert. Les ressources utilisées ensemble doivent appartenir au même contexte : tampons, textures, shaders, pipelines et handles ne peuvent pas être liés d’un contexte à un autre.'
+concepts.execution.context.description: 'Un {graphicsContext} relie l’application à un périphérique GPU par l’API graphique choisie et fournit ses files graphiques, de calcul et de transfert. Les ressources utilisées ensemble doivent appartenir au même contexte : tampons, textures, shaders, pipelines et handles ne peuvent pas être liés d’un contexte à un autre.'
concepts.execution.context.details: '{capabilities} indique le nom du périphérique et les fonctions prises en charge. Vérifiez {rayTracingSupported} et {meshShadingSupported} avant de créer les ressources nécessaires à ces fonctions. Les exemples de {link} et de {detail} effectuent ces vérifications à l’initialisation.'
concepts.execution.context.details.detail: mesh shading
concepts.execution.context.details.link: lancer de rayons
@@ -26,7 +26,7 @@ concepts.execution.pipelines.guidance.detail: exemple de calcul
concepts.execution.pipelines.guidance.link: rappel de rendu du triangle
concepts.execution.pipelines.title: 'État du pipeline'
concepts.execution.queues.description: '{graphicsQueue} constitue le point de départ habituel lorsqu’une image combine dessin, calcul et copies. Regrouper les opérations dépendantes dans une même file simplifie leur ordonnancement.'
-concepts.execution.queues.details: 'Des files distinctes permettent de soumettre séparément des tâches indépendantes, mais ne correspondent pas nécessairement à des moteurs matériels indépendants. Elles sont utiles lorsque les tâches peuvent bénéficier d’une exécution partiellement simultanée. Lorsqu’une file utilise les données produites par une autre, leurs soumissions doivent être reliées par une dépendance explicite.'
+concepts.execution.queues.details: 'Des files supplémentaires peuvent aider à exécuter en parallèle des tâches indépendantes, sans nécessairement correspondre à des moteurs matériels distincts. Lorsqu’une file utilise les données produites par une autre, relier leurs soumissions par une dépendance explicite.'
concepts.execution.queues.guidance: 'Dans une même file, des opérations dépendantes peuvent aussi nécessiter des barrières ou des transitions de texture pour que les accès ultérieurs voient les écritures précédentes. Ces dépendances mémoire sont distinctes de l’ordre de soumission. L’article {link} explique comment les exprimer.'
concepts.execution.queues.guidance.link: Synchronisation
concepts.execution.queues.table.computeQueue.workToRecord: 'Lancements de calcul et transferts compatibles, sans passe graphique.'
@@ -42,17 +42,15 @@ concepts.execution.recording.guidance: 'L’enregistrement construit la séquenc
concepts.execution.recording.title: 'Enregistrement et soumission'
concepts.execution.title: Modèle d’exécution
concepts.platforms.description: 'La présentation est gérée par l’application ou par un contrôle d’interface. Ce choix détermine qui obtient la texture de sortie de l’image, enregistre et soumet les commandes, puis présente le résultat. Cette texture de sortie est appelée drawable.'
-concepts.platforms.frame.context: 'Enregistrer les liaisons de pipeline et les commandes de dessin dans la passe, puis la terminer avant que le gestionnaire retourne. Le contrôle soumet les commandes et présente le résultat. Le gestionnaire ne doit ni soumettre le tampon de commandes ni libérer l’un ou l’autre des objets fournis. S’il modifie le layout de la texture de sortie, il doit rétablir {colorAttachment} avant de retourner pour permettre au contrôle d’effectuer la transition finale.'
-concepts.platforms.frame.description: 'Les contrôles implémentent {iZenithView}. L’application assigne {graphicsContext}, met à jour la scène dans {updateRequested} et enregistre le rendu dans {renderRequested} à partir de {renderEventArgs}.'
+concepts.platforms.frame.context: 'Enregistrer les liaisons de pipeline et les commandes de dessin dans la passe, puis la terminer avant que le gestionnaire retourne. Le gestionnaire ne doit ni soumettre le tampon de commandes ni libérer l’un ou l’autre des objets fournis. S’il modifie le layout de la texture de sortie, il doit rétablir {colorAttachment} avant de retourner pour permettre au contrôle d’effectuer la transition finale.'
+concepts.platforms.frame.description: 'Les contrôles implémentent {iZenithView}. L’application assigne {graphicsContext}, met à jour les données de la scène dans {updateRequested} et enregistre les commandes dans {renderRequested} à l’aide des {renderEventArgs} fournis.'
concepts.platforms.frame.details: 'Pour chaque image, le contrôle obtient une texture de sortie et un tampon de commandes, passe la texture au layout {colorAttachment}, puis appelle les gestionnaires de mise à jour et de rendu. Il soumet ensuite les commandes enregistrées et présente l’image par le mécanisme du framework.'
concepts.platforms.frame.guidance: 'Ajouter {usingZenithNET} au fichier. Pour un {iZenithView} initialisé, nommé {view} et associé à un contexte graphique, enregistrer ce gestionnaire afin de remplir sa texture de sortie avec une couleur :'
-concepts.platforms.frame.notes: 'La transition initiale utilise {undefined}, ce qui autorise l’abandon du contenu précédent. Dessiner ou réinitialiser l’image entière à chaque rendu. Pour conserver une accumulation ou un résultat en cache, utiliser une texture appartenant à l’application, puis dessiner cette texture dans la sortie du contrôle.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} fournit le format de couleur par défaut de ces intégrations.'
-concepts.platforms.frame.title: 'Rendu par un contrôle UI'
+concepts.platforms.frame.notes: 'La transition initiale utilise {undefined}, ce qui autorise l’abandon du contenu précédent. Dessiner ou effacer l’image entière à chaque rendu. Pour conserver une accumulation ou un résultat en cache, utiliser une texture appartenant à l’application, puis dessiner cette texture dans la texture de sortie du contrôle.'
+concepts.platforms.frame.title: 'Rendu dans un contrôle d’interface'
concepts.platforms.integration.context: 'WinForms, WPF et l’intégration Windows de WinUI s’exécutent sous Windows. Pour MAUI, installer la charge de travail de la plateforme cible et enregistrer le gestionnaire du contrôle avec {useZenithView}, comme dans {extensionsCs}.'
concepts.platforms.integration.description: 'L’interface d’événements est commune, mais la présentation dépend du framework :'
-concepts.platforms.integration.details: 'Ces implémentations diffèrent par la façon dont l’image GPU rejoint l’interface. La lecture vers un bitmap copie les pixels en mémoire CPU avant l’affichage. L’interopérabilité par texture partagée évite cette copie CPU, mais peut encore nécessiter des copies GPU et de la synchronisation. Pour choisir une intégration, considérer ce chemin de présentation en plus de l’événement commun {renderRequested}.'
-concepts.platforms.integration.guidance: 'Ajoutez le paquet d’intégration correspondant à votre framework d’interface via NuGet. Pour Avalonia, utilisez {avaloniaPackage}.'
+concepts.platforms.integration.details: 'Les intégrations d’interface présentent les images produites par le GPU de différentes manières. La lecture vers un bitmap copie les pixels en mémoire CPU avant l’affichage. L’interopérabilité par texture partagée évite cette copie, mais peut encore nécessiter des copies GPU et de la synchronisation. Pour choisir une intégration, considérer ce chemin de présentation en plus de l’événement commun {renderRequested}.'
concepts.platforms.integration.table.avalonia.integration: Avalonia
concepts.platforms.integration.table.avalonia.presentation: 'Effectue le rendu dans une texture, puis copie les pixels en mémoire CPU dans {writeableBitmap}. Implémentation : {zenithViewCs} et {surfaceCs}.'
concepts.platforms.integration.table.headings.integration: Intégration
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: 'Mécanisme de prés
concepts.platforms.integration.table.maui.integration: .NET MAUI
concepts.platforms.integration.table.maui.presentation: Utilise des surfaces natives sur Android, iOS et Mac Catalyst, et la composition par texture partagée sous Windows. Voir les {link}.
concepts.platforms.integration.table.maui.presentation.link: implémentations de plateforme
-concepts.platforms.integration.table.uno.integration: Voie Uno
+concepts.platforms.integration.table.uno.integration: Uno Platform
concepts.platforms.integration.table.uno.presentation: 'Copie les pixels en mémoire CPU dans {writeableBitmap}. Implémentation : {zenithViewUnoCs}.'
concepts.platforms.integration.table.winForms.integration: WinForms
concepts.platforms.integration.table.winForms.presentation: Crée une chaîne d’échange Zenith.NET pour le {hWND} du contrôle. Voir {zenithViewCs}.
@@ -70,22 +68,22 @@ concepts.platforms.integration.table.wpf.integration: WPF
concepts.platforms.integration.table.wpf.presentation: 'Importe une texture partagée Direct3D 11, puis copie son contenu, par interopérabilité Direct3D, vers une surface affichée par {d3DImage}. Voir {surfaceCs}.'
concepts.platforms.integration.title: 'Framework et présentation'
concepts.platforms.lifecycle.context: 'Pour créer des attachements compatibles, utiliser {descWidth}, {descHeight}, {descFormat} et {descSampleCount} de la texture de sortie fournie par l’événement de rendu. Cette texture donne les dimensions réelles de la cible ; elles ne doivent pas être déduites de la taille du contrôle dans la mise en page ni de l’échelle d’affichage.'
-concepts.platforms.lifecycle.description: 'La chaîne d’échange utilise la largeur et la hauteur du framebuffer en pixels, qui peuvent différer des dimensions logiques de la fenêtre avec la mise à l’échelle de l’affichage. Différer le rendu et le redimensionnement tant qu’une dimension est nulle. Obtenir {swapChainDrawable} pour chaque image : la chaîne d’échange possède cette texture et peut la remplacer après une présentation ou un redimensionnement.'
+concepts.platforms.lifecycle.description: 'La chaîne d’échange utilise la largeur et la hauteur du framebuffer en pixels, qui peuvent différer des dimensions logiques de la fenêtre avec la mise à l’échelle de l’affichage. Reporter le rendu et le redimensionnement de la chaîne d’échange tant qu’une dimension est nulle. Obtenir {swapChainDrawable} pour chaque image : la chaîne d’échange possède cette texture et peut la remplacer après une présentation ou un redimensionnement.'
concepts.platforms.lifecycle.details: 'Lors d’un changement de dimensions du framebuffer, attendre les accès GPU en cours aux anciennes images avant d’appeler {swapChainResize}. Pour remplacer la cible native de présentation, transmettre sa nouvelle description et ses handles à {swapChainRefresh}, une fois ces accès terminés. À l’arrêt, libérer la chaîne d’échange avant de détruire sa cible native.'
concepts.platforms.lifecycle.guidance: 'Si les textures de profondeur ou hors écran de l’application suivent la taille de la fenêtre, les recréer quand celle-ci change et mettre à jour les constantes contenant leurs handles. Le pipeline reste utilisable tant que les formats des attachements et les nombres d’échantillons correspondent. Le {link} montre comment recréer les textures tout en conservant le pipeline.'
-concepts.platforms.lifecycle.guidance.link: moteur de rendu du cube en rotation
+concepts.platforms.lifecycle.guidance.link: code de rendu du cube en rotation
concepts.platforms.lifecycle.title: 'Dimensions et durée de vie de la chaîne d’échange'
concepts.platforms.ownership.description: 'L’application possède le contexte assigné et ses ressources de rendu ; le contrôle possède ses ressources de présentation. Lorsque la propriété {graphicsContext} de la vue change, l’ordonnanceur recrée les ressources du contrôle pour le nouveau contexte. L’application doit également recréer ses pipelines, tampons et textures pour ce contexte.'
-concepts.platforms.ownership.details: 'Avant de remplacer des ressources de rendu, arrêter le traitement des images de la vue et attendre le travail GPU qui les utilise. Libérer ensuite seulement les anciennes ressources ou le contexte. L’application reste responsable de la libération du contexte assigné lors du retrait de la vue.'
+concepts.platforms.ownership.details: 'Avant de remplacer des ressources de rendu, arrêter la boucle de rendu de la vue et attendre le travail GPU qui les utilise. Libérer ensuite les anciennes ressources. Ne libérer le contexte que lorsque chaque vue a libéré ses ressources de présentation associées à ce contexte et que toutes les ressources de l’application créées à partir de ce contexte ont été libérées.'
concepts.platforms.ownership.guidance: 'Le {frameSchedulerCs} commun exécute les gestionnaires d’image via le dispatcher de l’interface de la vue. Limiter leur travail à la mise à jour de la scène et à l’enregistrement des commandes : un traitement CPU prolongé à cet endroit retarde aussi l’interface.'
concepts.platforms.ownership.title: 'Responsabilités de l’application et du contrôle'
concepts.platforms.surface.description: 'Le {link} utilise Silk.NET pour créer la fenêtre et traiter ses événements. Zenith.NET reçoit les handles natifs et les dimensions dans une description {surface}, à partir de laquelle il crée une {swapChain}. L’application reste responsable de la fenêtre du système d’exploitation.'
concepts.platforms.surface.description.link: 'tutoriel du triangle'
-concepts.platforms.surface.details: 'Les handles natifs doivent correspondre au backend :'
+concepts.platforms.surface.details: 'Les handles de surface dépendent de l’API graphique et du système de fenêtrage. Les combinaisons courantes sont :'
concepts.platforms.surface.guidance: 'L’hôte des exemples dans {appCs} prend en charge Windows, macOS et X11. Sous Linux, sa fenêtre fournit des handles Xlib ; une session Wayland doit donc disposer de XWayland pour l’exécuter. Une application Wayland native transmet ses handles de display et de surface via {surfaceWayland}.'
concepts.platforms.surface.table.android.backend: Vulkan sous Android.
concepts.platforms.surface.table.apple.backend: Metal sur les plateformes Apple.
-concepts.platforms.surface.table.headings.backend: 'Backend et plateforme'
+concepts.platforms.surface.table.headings.backend: 'API graphique et plateforme'
concepts.platforms.surface.table.headings.factory: Fabrique de surface
concepts.platforms.surface.table.headings.handles: Handles fournis par l’hôte
concepts.platforms.surface.table.wayland.backend: Vulkan avec un hôte Wayland natif.
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'Surfaces de présentation natives'
concepts.platforms.title: Intégration de plateforme
concepts.resources.allocation.context: 'Les ressources placées dans un tas dépendent de sa mémoire pendant toute leur durée de vie. Après leur dernière utilisation par le GPU, libérer les ressources avant de libérer le tas.'
concepts.resources.allocation.description: 'Un {heap} permet à l’application de gérer elle-même les allocations. Il fournit une mémoire où placer les ressources à des décalages explicites en octets. L’application choisit ces emplacements et suit les régions occupées.'
-concepts.resources.allocation.details: 'Pour chaque ressource, appeler {contextGetSizeAndAlignment} avec la description de tampon ou de texture qui servira à sa création. Réserver la taille renvoyée à un décalage multiple de l’alignement demandé, dans les limites du tas et sans chevaucher une allocation encore active. La taille d’une texture peut inclure du remplissage propre au backend ; le nombre de pixels et le nombre d’octets par pixel ne suffisent donc pas à calculer la taille de son allocation.'
+concepts.resources.allocation.details: 'Pour chaque ressource, appeler {contextGetSizeAndAlignment} avec la description de tampon ou de texture qui servira à sa création. Réserver la taille renvoyée à un décalage multiple de l’alignement demandé, dans les limites du tas et sans chevaucher une allocation encore active. La taille de l’allocation d’une texture peut inclure du remplissage ; le nombre de pixels et le nombre d’octets par pixel ne suffisent donc pas à la calculer.'
concepts.resources.allocation.guidance: 'Un tampon placé dans un tas doit déclarer la même résidence que ce tas. Pour les textures, utiliser un tas destiné exclusivement au GPU.'
concepts.resources.allocation.title: 'Allocation dans un tas'
concepts.resources.bufferUsages.table.constant.role: Paramètres de shader lus via une liaison de tampon de constantes.
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: 'Les transferts vers le GPU copient de
concepts.resources.transfers.details: 'Avant ces appels, résoudre les conflits d’accès avec les autres files. L’attente effectuée dans une méthode ne couvre que son propre transfert ; elle n’établit pas de dépendance avec une autre file. Pour les chemins qui accèdent directement à la mémoire mappée, il revient entièrement à l’appelant d’attendre les accès GPU en conflit.'
concepts.resources.transfers.guidance: 'Pour soumettre des transferts avec d’autres opérations GPU, les enregistrer avec {commandBufferUpload} ou {commandBufferDownload}. La mémoire source d’un transfert vers le GPU et la mémoire de destination d’un transfert depuis le GPU ont des exigences de durée de vie différentes :'
concepts.resources.transfers.item: 'Pendant l’appel de transfert vers le GPU, la bibliothèque copie les données source dans une mémoire de transfert temporaire. Le GPU lit ensuite cette copie intermédiaire. Le pointeur source de l’application n’est donc nécessaire que jusqu’au retour de l’appel.'
-concepts.resources.transfers.notes: 'Pour les transferts de texture, le pas de ligne est la distance en octets entre deux lignes successives des données CPU ; le pas de tranche est la distance entre deux tranches de profondeur. Ces valeurs permettent de copier les données entre la mémoire CPU et la texture GPU. L’article {link} explique pourquoi l’achèvement sur le GPU et la copie vers la destination CPU sont deux étapes distinctes.'
-concepts.resources.transfers.notes.link: Synchronisation
+concepts.resources.transfers.layouts: 'Les transferts de texture enregistrés n’incluent pas de transitions de layout. Un transfert vers la texture exige {copyDst} ; un transfert depuis la texture exige {copySrc}. Enregistrer le passage au layout correspondant avant la copie, puis, après la copie, le passage au layout requis par l’utilisation suivante.'
+concepts.resources.transfers.notes: 'Pour les transferts de texture, le pas de ligne est la distance en octets entre deux lignes successives des données CPU ; le pas de tranche est la distance entre deux tranches de profondeur. Ces valeurs permettent de copier les données entre la mémoire CPU et la texture GPU.'
concepts.resources.transfers.table.bufferDownload.transfer: 'Copie directement depuis la mémoire mappée pour {cpuReadOnly}. Sinon, soumet le transfert à la file de transfert et attend qu’il soit terminé.'
concepts.resources.transfers.table.bufferUpload.transfer: 'Copie directement dans la mémoire mappée pour {cpuWriteOnly}. Sinon, soumet le transfert à la file de transfert et attend qu’il soit terminé.'
concepts.resources.transfers.table.headings.method: Méthode
concepts.resources.transfers.table.headings.transfer: 'Comportement du transfert'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'Soumet la copie et les transitions de texture à la file graphique, puis attend leur achèvement. La sous-ressource sélectionnée reste dans le layout final demandé.'
-concepts.resources.transfers.title: 'Transferts immédiats et enregistrés'
+concepts.resources.transfers.title: 'Transferts immédiats et par tampon de commandes'
concepts.resources.usages.description: '{bufferUsages} et {textureUsages} sont des énumérations d’indicateurs qui déclarent les usages d’une ressource. Leurs valeurs sont affectées à {bufferDescUsages} et {textureDescUsages}, respectivement. Plusieurs membres peuvent être combinés avec {value} pour déclarer plusieurs usages.'
concepts.resources.usages.title: 'Usages des ressources'
-concepts.resources.views.description: 'Une {bufferView} décrit une région de tampon et l’interprétation de ses données. Une {textureView} sélectionne une plage de sous-ressources, ainsi qu’un type de texture et un format compatibles. Toutes deux désignent une mémoire existante, avec les usages déclarés à sa création. Les plages des vues décrivent l’accès, mais n’offrent pas de contrôle des limites uniforme dans les shaders sur tous les backends.'
+concepts.resources.views.description: 'Une {bufferView} décrit une région de tampon et l’interprétation de ses données. Une {textureView} sélectionne une plage de sous-ressources, ainsi qu’un type de texture et un format compatibles. Toutes deux désignent une mémoire existante, avec les usages déclarés à sa création. Les plages des vues décrivent l’accès, mais ne garantissent pas un contrôle uniforme des limites dans les shaders.'
concepts.resources.views.details: 'Le handle propre à une ressource fournit sa vue par défaut. Créer une vue distincte pour sélectionner une autre région ou une autre interprétation compatible. La vue et sa ressource sous-jacente doivent rester disponibles jusqu’à la fin de leur utilisation par le GPU : un handle ne maintient aucun de ces objets en vie. Si l’un d’eux est remplacé, mettre à jour les constantes contenant l’ancien {link}.'
concepts.resources.views.details.link: 'handle de ressource'
concepts.resources.views.title: 'Vues et ressources sous-jacentes'
concepts.shaders.binding.context: 'L’exemple de calcul affecte {inputTextureSampledHandle} à {input} et {outputTextureStorageHandle} à {output}. En Slang, le paramètre de type de {descriptorHandle} définit l’accès à la ressource :'
concepts.shaders.binding.description: '{setConstantBuffer} sélectionne un tampon existant et le décalage en octets à partir duquel le pipeline courant lit ses constantes. Transférer les paramètres dans cette mémoire avant leur utilisation par le shader. Si un travail GPU antérieur lit encore les mêmes octets, attendre sa fin avant de les mettre à jour.'
-concepts.shaders.binding.details: 'Préparer le tampon de commandes, le pipeline de calcul, le tampon de constantes rempli et le nombre de groupes de threads. Enregistrer ensuite le calcul dans l’ordre ci-dessous. Sélectionner d’abord le pipeline, car la liaison du tampon de constantes s’applique à ce pipeline :'
-concepts.shaders.binding.guidance: 'Ici, {commandBuffer} enregistre un calcul avec {computePipeline} et les paramètres de {constantBuffer}. Le tampon doit déclarer l’usage {bufferUsagesConstant} ; le décalage 0 sélectionne son début. Si plusieurs enregistrements de constantes partagent un tampon, le décalage de chacun doit aussi respecter l’alignement de liaison du backend, indépendamment de la disposition des champs à l’intérieur de l’enregistrement.'
-concepts.shaders.binding.notes: '{resourceHandle} contient deux champs de 32 bits dont l’interprétation dépend du backend. Leurs valeurs ne sont valables que dans le contexte où la ressource a été créée.'
+concepts.shaders.binding.details: 'Préparer le tampon de commandes, le pipeline de calcul, le tampon de constantes rempli et le nombre de groupes de threads. Enregistrer ensuite le lancement de calcul dans l’ordre ci-dessous. Sélectionner d’abord le pipeline, car la liaison du tampon de constantes s’applique à ce pipeline :'
+concepts.shaders.binding.guidance: 'Le tampon de constantes doit déclarer l’usage {bufferUsagesConstant}. Si plusieurs enregistrements de constantes partagent un tampon, le décalage initial de chacun doit respecter l’alignement de liaison requis, indépendamment de la disposition des champs à l’intérieur de l’enregistrement.'
+concepts.shaders.binding.notes: '{resourceHandle} contient deux champs de 32 bits dont l’interprétation dépend de l’implémentation de l’API graphique. Leurs valeurs ne sont valables que dans le contexte où la ressource a été créée.'
concepts.shaders.binding.reference: 'Conserver la ressource et toute vue utilisée pour obtenir son handle jusqu’à la fin du dernier accès du shader. Lorsqu’une texture ou une vue est remplacée, mettre à jour les constantes contenant encore son ancien handle. Les règles de propriété sont détaillées dans {link}.'
concepts.shaders.binding.reference.link: Gestion des ressources
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'Lecture d’éléments structurés de type {t} dans le shader'
@@ -176,8 +174,8 @@ concepts.shaders.binding.table.headings.slangFieldType: Type de champ Slang
concepts.shaders.binding.table.samplerHandle.access: 'État d’échantillonnage des textures'
concepts.shaders.binding.table.textureSampledHandle.access: 'Lecture de textures'
concepts.shaders.binding.table.textureStorageHandle.access: 'Lecture et écriture de textures de stockage'
-concepts.shaders.binding.title: 'Constantes et handles de ressources'
-concepts.shaders.compilation.description: '{zenithCompiler} compile un point d’entrée Slang en {shaderDesc}. {graphicsApi} détermine la cible : DXIL pour DirectX 12, bibliothèque Metal pour Metal, SPIR-V pour Vulkan.'
+concepts.shaders.binding.title: 'Tampons de constantes et handles de ressources'
+concepts.shaders.compilation.description: '{zenithCompiler} compile un point d’entrée Slang et renvoie un {shaderDesc}. La propriété {graphicsApi} du contexte détermine le format de sortie : {dxil} pour DirectX 12, {metallib} pour Metal ou {spirv} pour Vulkan.'
concepts.shaders.compilation.details: 'Avec un contexte graphique nommé {context} déjà créé, compiler le shader du triangle à partir de la copie placée à côté de l’exécutable :'
concepts.shaders.compilation.guidance: 'Le nom de point d’entrée {vSMain} doit correspondre à la déclaration dans le fichier de shader. Compiler les shaders et créer les pipelines à l’initialisation, puis réutiliser les pipelines pendant le rendu. Les objets shader peuvent être libérés une fois le pipeline créé, comme dans le tutoriel {link}.'
concepts.shaders.compilation.guidance.link: Premier triangle
@@ -193,27 +191,27 @@ concepts.shaders.layout.description: 'Pour les sommets, {inputLayout} décrit le
concepts.shaders.layout.details: 'Les tampons de constantes contiennent des paramètres de shader, et les tampons structurés des tableaux d’éléments typés. Leur disposition suit les déclarations Slang, et non {inputLayout}. Les décalages des champs C#, les tailles des éléments et le remplissage doivent correspondre à la disposition mémoire du shader compilé. Un type C# non managé peut être copié sous forme d’octets, mais sa disposition mémoire ne correspond pas nécessairement à celle attendue par le shader : un {float3} compact dans un sommet peut nécessiter un autre alignement dans un tampon de shader.'
concepts.shaders.layout.guidance: 'Les paramètres de shader peuvent contenir des handles de ressources en plus des valeurs ordinaires. Un handle désigne une mémoire déjà allouée : le copier dans un tampon de constantes ne copie donc pas le contenu de la ressource.'
concepts.shaders.layout.notes: 'La déclaration correspondante dans {computeShaderSlang} est :'
-concepts.shaders.layout.reference: 'Les deux dimensions occupent les huit premiers octets, suivis de deux handles de huit octets chacun. L’exemple C# réserve 256 octets pour l’ensemble de l’enregistrement. Pour un autre enregistrement, déterminer la taille à partir de ses propres champs et des contraintes de disposition et d’alignement.'
+concepts.shaders.layout.reference: 'Les champs C# occupent les 24 premiers octets : huit pour les dimensions et huit pour chacun des deux handles. Le reste de l’enregistrement de 256 octets sert de remplissage. Pour un autre bloc de paramètres, faire correspondre les décalages des champs à sa disposition dans le shader. Si plusieurs enregistrements partagent un tampon, prévoir entre eux assez de remplissage pour respecter l’alignement de liaison requis.'
concepts.shaders.layout.title: 'Disposition des données'
concepts.shaders.matrices.description: 'Le compilateur choisit un stockage des matrices par lignes contiguës. Le {link} place trois valeurs {matrix4x4} aux décalages de 0, 64 et 128 octets. Son {detail} applique {mulVectorMatrix} dans l’ordre modèle, vue et projection.'
concepts.shaders.matrices.description.detail: shader
-concepts.shaders.matrices.description.link: moteur de rendu du cube en rotation
+concepts.shaders.matrices.description.link: code de rendu du cube en rotation
concepts.shaders.matrices.details: 'L’ordre de stockage définit la disposition des éléments de matrice en mémoire ; l’ordre de multiplication définit la transformation. Les conventions C# et Slang doivent correspondre.'
concepts.shaders.matrices.title: 'Conventions matricielles'
concepts.shaders.title: Données de shaders et liaison
-concepts.synchronization.backends.description: 'DirectX 12 et Vulkan encodent les transitions de texture sous forme de changements de layout et d’accès. L’implémentation de {transition} dans Zenith.NET n’effectue pas d’opération équivalente sur Metal. Le backend Metal regroupe les commandes dans des encodeurs de rendu et de calcul, puis insère des barrières de visibilité à la fermeture d’un encodeur. Les opérations dépendantes dans un même encodeur, comme deux calculs successifs, utilisent des appels explicites à {barrier}.'
-concepts.synchronization.backends.details: 'Dans l’{link}, l’ouverture de la passe de rendu ferme l’encodeur de calcul et rend sa sortie visible aux commandes graphiques. Deux calculs successifs restent en revanche dans le même encodeur. Leur dépendance exige donc une barrière, même si une transition de texture est enregistrée entre eux. Les séquences de commandes portables doivent ainsi tenir compte des dépendances d’accès autant que des layouts de texture.'
+concepts.synchronization.backends.description: 'DirectX 12 et Vulkan encodent les transitions de texture sous forme de changements de layout et d’accès. Dans l’implémentation Metal de Zenith.NET, {transition} n’effectue pas d’opération GPU équivalente. Cette implémentation regroupe les commandes dans des encodeurs de rendu et de calcul, puis insère des barrières de visibilité à la fermeture d’un encodeur. Les opérations dépendantes dans un même encodeur, comme deux calculs successifs, exigent des appels explicites à {barrier}.'
+concepts.synchronization.backends.details: 'Dans l’{link}, l’ouverture de la passe de rendu ferme l’encodeur de calcul et rend sa sortie visible aux commandes graphiques. Deux calculs successifs restent en revanche dans le même encodeur. Leur dépendance exige donc une barrière, même si une transition de texture est enregistrée entre eux.'
concepts.synchronization.backends.details.link: exemple de calcul
-concepts.synchronization.backends.title: 'Comportement des backends'
+concepts.synchronization.backends.title: 'Synchronisation selon l’API graphique'
concepts.synchronization.barriers.context: 'Choisir des étapes qui couvrent les accès concernés et sont prises en charge par la file. {barrierStagesAll} inclut toutes les étapes disponibles ; une sélection plus restreinte convient lorsque la dépendance ne concerne que certaines d’entre elles.'
concepts.synchronization.barriers.description: 'Considérons deux calculs enregistrés dans le même tampon de commandes : le premier écrit des données de simulation, le second les lit. Une barrière entre les deux garantit que le second voit les écritures achevées. Pour un tampon de stockage, elle ordonne les accès sans transition de layout de texture :'
concepts.synchronization.barriers.details: 'Le premier argument indique les étapes qui ont produit les données ; le second indique celles qui vont les utiliser. Ensemble, ils décrivent l’ordre d’exécution et la visibilité mémoire nécessaires entre les deux calculs.'
-concepts.synchronization.barriers.guidance: 'La {link} applique ce principe entre les étapes de simulation. Chaque barrière suit le calcul qui produit les données et précède celui qui les utilise.'
+concepts.synchronization.barriers.guidance: 'La {link} applique ce principe entre les étapes de simulation.'
concepts.synchronization.barriers.guidance.link: simulation FluidTank
concepts.synchronization.barriers.title: 'Barrières de pipeline'
concepts.synchronization.dependencies.description: 'Pour chaque ressource, repérer les accès qui portent sur les mêmes données. Si l’un d’eux écrit, préserver l’ordre requis entre eux. Deux lectures ne sont pas en conflit, même si les contraintes de layout et de présentation continuent de s’appliquer. Les mises à jour CPU et la libération des ressources doivent aussi attendre que le GPU ait fini d’utiliser la mémoire concernée.'
concepts.synchronization.dependencies.details: 'Le mécanisme dépend du lieu d’exécution des opérations :'
-concepts.synchronization.dependencies.guidance: 'Un traitement peut nécessiter plusieurs mécanismes. Une texture produite sur une autre file demande par exemple une dépendance entre soumissions et le layout adapté à son prochain usage. Ces opérations ne nécessitent de bloquer le CPU que si celui-ci doit lui-même accéder aux données ou libérer leur mémoire.'
+concepts.synchronization.dependencies.guidance: 'Lorsqu’une file écrit dans une texture utilisée par une autre, soumettre le travail avec une dépendance et enregistrer la transition de layout nécessaire. Aucune de ces étapes ne bloque le CPU. Attendre la fin du travail avant que le CPU accède aux données ou libère la ressource.'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: Appeler {wait} sur la valeur d’achèvement pertinente.
concepts.synchronization.dependencies.table.cpuAccess.situation: 'Un accès CPU ou une libération de ressource dépend de la fin du travail GPU'
concepts.synchronization.dependencies.table.crossQueue.mechanism: 'Transmettre la valeur {timelineValue} du producteur à l’appel {submit} du consommateur.'
@@ -227,7 +225,7 @@ concepts.synchronization.dependencies.table.pipelineStages.situation: Étapes GP
concepts.synchronization.dependencies.title: 'Dépendances d’accès'
concepts.synchronization.description: 'La synchronisation fixe l’ordre dans lequel les opérations accèdent aux données partagées et garantit que les suivantes voient les résultats dont elles ont besoin. Dans une dépendance entre écriture et lecture, l’opération qui écrit produit les données et celle qui lit les consomme. Les barrières et les transitions de texture coordonnent les accès GPU ; les lignes de temps relient les soumissions et permettent au CPU d’attendre la fin du travail GPU.'
concepts.synchronization.layouts.context: 'Utiliser {undefined} comme layout précédent lorsque le contenu peut être abandonné, par exemple pour une nouvelle image ou un attachement entièrement réinitialisé. Pour conserver le contenu afin de le charger, de l’échantillonner ou de l’accumuler, utiliser le layout de l’accès précédent.'
-concepts.synchronization.layouts.description: 'Les indicateurs d’usage d’une texture déclarent ses rôles autorisés. {textureLayout} décrit l’accès à une sous-ressource à un moment donné de la séquence de commandes. Cette sous-ressource est identifiée par un niveau de mip et une couche de tableau. Lorsque l’accès change, enregistrer une transition. Par exemple, l’exemple de calcul écrit sa texture de sortie dans le layout {storage}, puis la prépare à être échantillonnée dans une passe graphique :'
+concepts.synchronization.layouts.description: 'Les indicateurs d’usage d’une texture déclarent ses rôles autorisés. {textureLayout} décrit l’accès à une sous-ressource à un moment donné de la séquence de commandes. Cette sous-ressource est identifiée par un niveau de mip et une couche de tableau. Lorsque l’accès change, enregistrer une transition. Ainsi, l’exemple de calcul écrit sa texture de sortie dans le layout {storage}, puis la prépare à être échantillonnée dans une passe graphique :'
concepts.synchronization.layouts.details: '{outputTexture} a l’usage {sampledStorage}, et la sous-ressource retenue est en {storage}. {default} sélectionne le niveau mip 0 et la couche 0. Les autres niveaux et couches ne sont pas modifiés.'
concepts.synchronization.layouts.guidance: 'Pour {transition}, fournir le layout de l’utilisation précédente de la sous-ressource. L’application suit cet état lorsqu’elle enregistre les commandes et transmet les textures entre étapes de rendu.'
concepts.synchronization.layouts.title: 'Layouts de texture'
@@ -256,7 +254,7 @@ home.entries.reference.category: Référence
home.entries.reference.description: 'Consulter les types, membres et déclarations de l’API'
home.entries.reference.title: Référence de l’API
home.entries.samples.action: Parcourir les exemples
-home.entries.samples.category: Exemples
+home.entries.samples.category: Exemples de code
home.entries.samples.description: 'Des exemples exécutables de techniques graphiques et de calcul'
home.entries.samples.title: Exemples
home.entries.title: 'Documentation'
@@ -265,10 +263,10 @@ home.entries.tutorial.category: Tutoriel
home.entries.tutorial.description: 'D’un projet vide au premier triangle à l’écran'
home.entries.tutorial.title: Premier triangle
home.introduction.accent: 'avec .NET'
-home.introduction.description: 'Zenith.NET fournit une API commune pour le rendu et le calcul avec DirectX, Metal et Vulkan'
+home.introduction.description: 'Zenith.NET fournit une API commune pour le rendu et le calcul avec DirectX 12, Metal 4 et Vulkan 1.4'
home.introduction.title: 'Le rendu multiplateforme{lineBreak}{accent}'
-home.meta.description: 'Développez des applications graphiques et de calcul multiplateformes avec .NET et une API commune pour DirectX, Metal et Vulkan'
-home.scene.description: 'Géométrie en rotation interactive. Faire glisser ou utiliser les touches fléchées pour changer le point de vue.'
+home.meta.description: 'Développez des applications graphiques et de calcul multiplateformes avec .NET et une API commune pour DirectX 12, Metal 4 et Vulkan 1.4'
+home.scene.description: 'Géométrie en rotation interactive. Faites-la glisser ou utilisez les touches fléchées pour changer le point de vue.'
home.scene.label: Affichage de la géométrie
home.scene.surface: Surface
home.scene.wireframe: Fil de fer
@@ -277,84 +275,78 @@ learning.concepts.description: 'Choisir les usages des ressources, décrire les
learning.concepts.execution.description: 'Enregistrement, soumission et durée de vie des ressources'
learning.concepts.platforms.description: 'Présentation native et contrôles de rendu UI'
learning.concepts.resources.description: 'Usages des ressources, placement mémoire et vues'
-learning.concepts.shaders.description: 'Conventions de disposition et de liaison entre C# et Slang'
+learning.concepts.shaders.description: 'Conventions de disposition des données et de liaison pour C# et Slang'
learning.concepts.synchronization.description: 'Dépendances, visibilité et achèvement'
learning.concepts.title: Concepts fondamentaux
-learning.description: 'Commencez par le tutoriel du triangle pour créer votre première application. Les articles de fond expliquent ensuite la gestion des ressources, les données des shaders et la synchronisation. Les exemples permettent d’aborder séparément chaque technique.'
+learning.description: 'Commencez par le tutoriel du triangle pour créer votre première application. Consultez ensuite les articles sur la gestion des ressources, les données des shaders et la synchronisation, ou choisissez un exemple pour la technique que vous souhaitez mettre en œuvre.'
learning.entries.samples.action: Parcourir les exemples
-learning.entries.samples.description: 'Implémentations C# et Slang de géométrie, calcul, requêtes de rayons et mesh shading'
+learning.entries.samples.description: 'Exemples C# et Slang de géométrie, de calcul, de requêtes de rayons et de mesh shading'
learning.entries.tutorial.action: Ouvrir le tutoriel
-learning.entries.tutorial.description: 'Une application console qui ouvre une fenêtre et rend un triangle'
+learning.entries.tutorial.description: 'Une application console qui ouvre une fenêtre et affiche un triangle'
learning.meta.description: 'Tutoriels et concepts du modèle de programmation de Zenith.NET'
learning.title: Apprendre
reference.description: 'Référence des ressources, commandes et intégrations de plateforme'
reference.entries.commands.description: 'Commandes graphiques, de calcul et de transfert'
reference.entries.commands.label: 'Enregistrer des commandes'
-reference.entries.context.description: 'Création de ressources GPU pour le backend sélectionné'
+reference.entries.context.description: 'Création de ressources GPU au moyen d’un contexte graphique'
reference.entries.context.label: Commencer ici
reference.meta.description: 'Espaces de noms, types et membres de Zenith.NET'
reference.navigation.core: 'Référence de l’API principale'
reference.title: Référence de l’API
-samples.computeShader.description: 'L’exemple charge l’image {assetsTexturesShokoPng}, la convertit en niveaux de gris par un calcul GPU et affiche la texture de sortie. La conversion n’a lieu qu’une fois ; les images suivantes affichent le même résultat. Le moteur de rendu montre comment lier des textures échantillonnées et accessibles en écriture, arrondir le nombre de groupes de threads à l’entier supérieur pour couvrir l’image et vérifier ses limites dans le shader.'
+samples.computeShader.description: 'Un shader de calcul convertit une image couleur en niveaux de gris et illustre ainsi le traitement d’images sur le GPU.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: Shader de calcul
-samples.cube.description: 'Le cube ajoute le dessin indexé, les matrices de modèle, de vue et de projection dans un tampon de constantes, ainsi que le test de profondeur. Sa texture de profondeur et de stencil {d32FloatS8UInt} est recréée au redimensionnement.'
+samples.cube.description: 'Un cube en rotation introduit la géométrie indexée, les transformations 3D et le test de profondeur.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: Cube en rotation
-samples.description: 'Chaque exemple associe un moteur de rendu C# à son shader Slang et se concentre sur une technique. La configuration complète de l’application et la séquence de rendu sont décrites dans {link}.'
-samples.description.link: Premier triangle
+samples.description: 'Ces exemples abordent le rendu et le calcul, du simple triangle aux applications interactives et aux outils de diagnostic.'
samples.execution.description: 'Exécutez le projet {link} et choisissez un exemple dans le menu de la console.'
samples.execution.description.link: ZenithTutorials
samples.execution.title: 'Exécution des exemples'
-samples.host.description: '{appCs} initialise le contexte, la fenêtre et la chaîne d’échange. À chaque image, l’hôte obtient un tampon de commandes, appelle le moteur choisi, soumet les commandes et présente le résultat. {iRendererCs} définit les opérations de mise à jour, de rendu, de redimensionnement et de libération.'
-samples.host.details: 'Les moteurs de rendu de calcul et de lancer de rayons produisent des textures hors écran. {texturePresenterCs} et {presentTextureSlang} les dessinent dans la texture de sortie courante ; l’hôte commun soumet ensuite les commandes et présente l’image.'
-samples.host.title: 'Hôte et présentation'
-samples.indirectDrawing.description: 'Le dessin indirect affiche plusieurs instances de cube à partir d’un tampon d’arguments de dessin indexé et d’un tampon structuré de données par instance. Le CPU fournit les arguments et actualise les transformations.'
+samples.indirectDrawing.description: 'Une grille de cubes en rotation, chacun avec sa propre couleur, illustre le dessin indirect à partir d’un tampon d’arguments de dessin.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: Dessin indirect
-samples.meshShading.description: 'Un shader de tâches élimine les instances de sphères non visibles, puis transmet les indices restants au shader de maillage qui produit la géométrie. Le moteur vérifie {contextCapabilitiesMeshShadingSupported} avant de créer le pipeline.'
+samples.meshShading.description: 'Cet exemple utilise des shaders de tâches et de maillage pour afficher une grille de sphères colorées, sans traiter celles qui se trouvent hors du champ de la caméra. Nécessite la prise en charge du mesh shading.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: Mesh Shading
-samples.rayTracing.description: 'Cet exemple construit les structures d’accélération de niveau inférieur et supérieur d’un sol et de sphères procédurales, puis effectue des requêtes de rayons directement dans un shader de calcul. Il vérifie {contextCapabilitiesRayTracingSupported} avant l’initialisation.'
+samples.rayTracing.description: 'Cet exemple utilise des requêtes de rayons pour afficher des sphères réfléchissantes et des ombres sur un sol en damier. Nécessite la prise en charge du lancer de rayons.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: Lancer de rayons
samples.title: Exemples
-samples.triangle.description: 'Le triangle associe un tampon de sommets à la disposition d’entrée correspondante et dessine trois sommets au moyen d’un pipeline graphique.'
+samples.triangle.description: 'Un triangle dont les couleurs varient progressivement entre les sommets présente les bases du pipeline graphique.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: Tutoriel complet
samples.triangle.title: Bonjour triangle
-samples.workloads.description: 'Le {link} du dépôt principal contient des applications plus complètes qui utilisent le code source de la bibliothèque.'
+samples.workloads.description: 'Le {link} du dépôt Zenith.NET contient ces applications et utilitaires.'
samples.workloads.description.link: répertoire Experiments
-samples.workloads.details: 'Les applications fenêtrées utilisent les mêmes chemins Windows, macOS et Linux/X11. Les contrôles Avalonia, WinForms, WPF, WinUI/Uno et MAUI sont décrits dans {link}, avec leur cycle d’image et leur code d’implémentation.'
-samples.workloads.details.link: Intégration de plateforme
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: CornellBox
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Tracé de chemins, débruitage, mappage tonal, agrandissement de l’image et contrôles ImGui. Nécessite la prise en charge du lancer de rayons.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Une scène d’intérieur interactive pour observer l’éclairage et les reflets. Nécessite la prise en charge du lancer de rayons.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: FluidTank
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Simulation de fluide par calcul, dépendances entre étapes de simulation et rendu de surface multipasse.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Une simulation d’eau dans un réservoir, avec une vue de la surface et une vue des particules.'
samples.workloads.table.headings.example: Exemple
-samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Techniques et prérequis'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Description'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: InkCanvas
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Dessin Skia et gestion des entrées dans une fenêtre native. Nécessite le backend et la bibliothèque native Skia pour la plateforme cible.
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Une zone de dessin pour tracer et effacer des traits à main levée.
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: PlatformDetection
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Tente de créer un contexte pour chaque backend et rapporte les capacités du périphérique. Un échec est indiqué comme une absence de prise en charge ; il peut provenir du périphérique, du pilote ou d’une dépendance d’exécution manquante.'
-samples.workloads.title: 'Applications complètes'
-tutorial.context.description: 'Un {graphicsContext} relie l’application au GPU par l’intermédiaire d’un backend et fournit les méthodes de création des ressources de rendu.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Un outil en console qui indique les API graphiques disponibles et les capacités du périphérique.'
+samples.workloads.title: 'Applications et utilitaires'
+tutorial.context.description: 'Un {graphicsContext} relie l’application au GPU au moyen de l’API graphique choisie et fournit les méthodes de création des ressources de rendu.'
tutorial.context.details: 'Insérez l’initialisation du contexte {emphasis} :'
tutorial.context.details.emphasis: après les directives using, avant {iWindowWindow}
-tutorial.context.guidance: 'Chaque branche sélectionne le backend de la plateforme et demande la validation. Les messages de {validationMessage} sont affichés dans la console.'
+tutorial.context.guidance: 'Chaque branche demande la validation de son API graphique. Le gestionnaire affiche les diagnostics de {validationMessage} lorsque l’implémentation en fournit.'
tutorial.context.imports: 'Ajoutez les directives using suivantes au début de {programCs} :'
tutorial.context.title: 'Contexte graphique'
tutorial.description: 'Ce tutoriel part d’un projet console .NET vide pour créer une application qui ouvre une fenêtre et dessine un triangle coloré.'
tutorial.details: 'Le tutoriel comporte trois étapes de vérification : une fenêtre vide, un fond uni, puis le triangle coloré. Exécutez l’application à chaque étape avant d’ajouter la partie suivante.'
tutorial.draw.context: 'Les arguments de {draw} sont :'
tutorial.draw.description: 'Dans {windowRender}, remplacez {addTheTriangleDrawCommandsHereLater} par ces commandes, entre {beginRenderPass} et {endRenderPass} :'
-tutorial.draw.details: '{setPipeline} sélectionne les shaders et l’état de rendu. Cet appel doit précéder la liaison du tampon de sommets, car le backend l’interprète selon la disposition d’entrée du pipeline.'
+tutorial.draw.details: '{setPipeline} sélectionne les shaders et l’état de rendu. Sélectionnez le pipeline avant de lier le tampon de sommets pour que sa disposition d’entrée détermine la lecture des données.'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} lie les données de sommets déjà transférées, à partir du décalage de 0 octet, à l’emplacement d’entrée 0. Celui-ci correspond à l’unique entrée de {inputLayouts}.'
-tutorial.draw.notes: 'Ces appels enregistrent les commandes de dessin. L’appel {submitWait} déjà présent les soumet et attend que le GPU les termine ; {present} demande ensuite l’affichage de l’image achevée. Conservez l’initialisation avec la couleur de fond au début de la passe pour donner un contenu défini à la zone extérieure au triangle.'
+tutorial.draw.notes: 'Conservez l’effacement au début de la passe pour que la zone extérieure au triangle ait une couleur de fond définie.'
tutorial.draw.table.firstInstance.meaning: Commencer la numérotation des instances à zéro.
tutorial.draw.table.firstVertex.meaning: Commencer avec le premier sommet dans le tampon.
tutorial.draw.table.headings.argument: Argument
@@ -367,43 +359,42 @@ tutorial.execution.description: 'Compilez et lancez le projet {firstTriangle}.'
tutorial.execution.details: 'Un triangle doit apparaître sur fond sombre, rouge en haut, vert en bas à droite et bleu en bas à gauche. L’interpolation des couleurs des sommets forme un dégradé continu à l’intérieur.'
tutorial.execution.guidance: 'Le redimensionnement modifie les dimensions de l’image en pixels, mais les coordonnées des sommets restent identiques. Le viewport les adapte à la nouvelle largeur et à la nouvelle hauteur. Le triangle s’étire donc lorsque le rapport largeur/hauteur de la fenêtre change.'
tutorial.execution.title: 'Exécution de l’application'
-tutorial.frame.commands.context: 'Après {endRenderPass}, la seconde transition prépare la sortie pour la présentation. {submit} termine l’enregistrement et soumet le tampon ; {wait} bloque jusqu’à l’achèvement. {present} demande ensuite l’affichage.'
+tutorial.frame.commands.context: 'Après {endRenderPass}, la seconde transition prépare la texture de sortie pour la présentation. {submit} termine l’enregistrement et soumet le tampon de commandes ; {wait} bloque jusqu’à la fin de cette soumission. {present} demande ensuite l’affichage de l’image rendue.'
tutorial.frame.commands.description: 'Une passe de rendu regroupe les opérations de dessin qui écrivent dans les mêmes attachements. Ici, la texture de sortie de la chaîne d’échange reçoit les couleurs produites par le rendu. {colorAttachmentClear} indique que cet attachement doit être initialisé avec une couleur RGBA et que son contenu doit être conservé à la fin de la passe. {beginRenderPass} enregistre le début de la passe avec ces paramètres.'
tutorial.frame.commands.details: 'La collection contient un attachement de couleur. {null} indique que la passe ne possède pas d’attachement de profondeur et de stencil.'
-tutorial.frame.commands.guidance: '{beginRenderPass} règle le viewport et le rectangle de découpe sur tout l’attachement. Le viewport convertit les coordonnées de rendu en positions de pixels ; le rectangle de découpe limite la zone où l’écriture est autorisée.'
+tutorial.frame.commands.guidance: '{beginRenderPass} règle le viewport et le rectangle de découpe sur tout l’attachement. Le viewport convertit les coordonnées de rendu en positions de pixels ; le rectangle de découpe limite les pixels que les opérations de dessin peuvent modifier.'
tutorial.frame.commands.title: 'Effacement, soumission et présentation'
-tutorial.frame.description: 'Commencez par remplir la fenêtre d’une couleur de fond. Cette opération s’appelle l’effacement. Lorsque le fond s’affiche, la surface, la soumission et la présentation fonctionnent ensemble ; vous pouvez ajouter les sommets et les shaders du triangle.'
-tutorial.frame.details: 'Silk.NET appelle le rappel de rendu lorsqu’une image doit être produite. L’argument de temps écoulé reste inutilisé et porte le nom {value}. Enregistrez le rappel {emphasis} :'
+tutorial.frame.description: 'Commencez par remplir la fenêtre d’une couleur uniforme : c’est l’effacement. Si la couleur apparaît, la soumission des commandes et la présentation fonctionnent. Ajoutez ensuite les sommets et les shaders du triangle.'
+tutorial.frame.details: 'Silk.NET appelle le rappel de rendu lorsqu’une image doit être produite. Enregistrez le rappel {emphasis} :'
tutorial.frame.details.emphasis: avant {windowRun}
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} renvoie un tampon prêt à enregistrer. L’enregistrement décrit le travail GPU ; l’exécution ne commence qu’après soumission.'
+tutorial.frame.target.description: 'Une file de commandes reçoit le travail enregistré pour le faire exécuter par le GPU. {graphicsQueueCommandBuffer} renvoie un tampon de commandes provenant de la file graphique, dont l’enregistrement est déjà en cours. Les commandes enregistrées définissent le travail du GPU ; son exécution ne commence qu’après la soumission.'
tutorial.frame.target.details: 'Le layout d’une texture décrit le type d’accès nécessaire à une opération. Le premier appel à {transition} prépare la texture de sortie à servir d’attachement de couleur. Ici, {default} sélectionne le niveau de mip 0 et la couche de tableau 0, soit l’image de base de cette texture. Comme la passe remplit toute l’image avec la couleur de fond, {undefined} autorise l’abandon de son contenu précédent.'
tutorial.frame.target.guidance: 'Utilisez la texture de sortie courante à chaque image, car la présentation peut faire passer la chaîne d’échange à une autre texture.'
-tutorial.frame.target.title: 'Préparation de la sortie'
+tutorial.frame.target.title: 'Préparation de la texture de sortie'
tutorial.frame.title: 'Première image'
tutorial.geometry.data.description: 'Ajoutez le tableau de sommets {emphasis}. L’initialisation des ressources suivantes reste aussi avant ce rappel, dans l’ordre indiqué.'
tutorial.geometry.data.description.emphasis: avant {windowRender}
-tutorial.geometry.data.details: 'Chaque entrée construit un {vertex}. Les deux expressions {new} internes donnent sa position {vector3} et sa couleur {vector4}. Les positions définissent les coins supérieur, inférieur droit et inférieur gauche. Le shader de sommets ajoute {w} comme quatrième coordonnée. Avec w = 1, x et y sont des coordonnées normalisées du périphérique : -1 et +1 marquent les bords, 0 le centre, indépendamment des dimensions en pixels.'
+tutorial.geometry.data.details: 'Les trois positions définissent les coins supérieur, inférieur droit et inférieur gauche. Dans cet exemple, les coordonnées x et y vont de -1 à +1 sur l’image : 0 correspond au centre, les valeurs positives de x se trouvent à droite et celles de y en haut.'
tutorial.geometry.data.guidance: 'Chaque couleur comporte des composantes rouge, verte, bleue et alpha, avec alpha égal à 1. Les trois sommets sont dans le même plan, à z = 0.'
tutorial.geometry.data.title: 'Positions et couleurs'
tutorial.geometry.description: 'Chacun des trois sommets possède une position et une couleur. Le GPU détermine la forme du triangle à partir des positions et interpole les couleurs sur sa surface.'
tutorial.geometry.format.description: 'Ajoutez la déclaration de sommet {emphasis} :'
tutorial.geometry.format.description.emphasis: à la fin de {programCs}, après les instructions de nettoyage
-tutorial.geometry.format.details: '{file} limite le type au fichier {programCs}, tandis que {layoutKindSequential} conserve l’ordre de déclaration de ses champs. {position} contient trois nombres flottants de 32 bits à partir du décalage de 0 octet ; {color} en contient quatre à partir du décalage de 12 octets. Chaque sommet occupe donc 28 octets. La disposition d’entrée décrira cette organisation pour que le GPU lise correctement les champs.'
+tutorial.geometry.format.details: '{layoutKindSequential} conserve l’ordre de déclaration des champs. {position} contient trois nombres flottants de 32 bits à partir du décalage de 0 octet ; {color} en contient quatre à partir du décalage de 12 octets. Chaque sommet occupe donc 28 octets. La disposition d’entrée décrira cette organisation pour que le GPU lise correctement les champs.'
tutorial.geometry.format.imports: 'Ajoutez ces directives using au début de {programCs} pour les types vectoriels et l’attribut de disposition mémoire des structures :'
tutorial.geometry.format.title: 'Représentation d’un sommet'
tutorial.geometry.title: 'Données de sommets'
tutorial.geometry.upload.context: '{fixed} empêche le ramasse-miettes de déplacer le tableau pendant l’utilisation de son adresse. Pour ce tampon accessible en écriture au CPU, {upload} mappe la mémoire, copie les données, puis termine le mapping avant de retourner. Le tableau ne doit donc rester épinglé que pendant l’appel. Transférez les sommets une seule fois à l’initialisation et conservez le tampon jusqu’à la fin du rendu.'
tutorial.geometry.upload.description: 'Placez les sommets dans un {buffer} afin que le GPU puisse les lire pendant le dessin. Ajoutez l’allocation et le transfert immédiatement après le tableau :'
-tutorial.geometry.upload.details: '{sizeofVertexVerticesLength} représente trois sommets de 28 octets, soit 84 octets. {bufferUsagesVertex} déclare l’accès en entrée de sommets, {cpuWriteOnly} autorise l’initialisation directe par le CPU. Le pas du descripteur indique la taille d’un élément ; la disposition d’entrée précise ensuite chaque attribut.'
+tutorial.geometry.upload.details: '{sizeofVertexVerticesLength} représente trois sommets de 28 octets, soit 84 octets. {bufferUsagesVertex} déclare l’usage du tampon pour les données de sommets, tandis que {cpuWriteOnly} autorise son initialisation directe par le CPU. Le pas du descripteur indique la taille de chaque élément ; la disposition d’entrée définie plus loin précise comment lire chaque attribut.'
tutorial.geometry.upload.guidance: 'L’allocation n’initialise pas le contenu. {upload} copie le tableau au décalage de destination 0 à partir du pointeur source et du nombre d’octets de la description.'
tutorial.geometry.upload.imports: 'Dans {programCs}, ajoutez {bufferAlias} aux directives using pour distinguer le type de tampon de Zenith.NET de {systemBuffer}.'
-tutorial.geometry.upload.notes: 'Ajoutez {vertexBufferDispose} juste avant {swapChainDispose} à la fin de {programCs}. Le stockage réservé au GPU et les transferts pour de plus grandes géométries sont présentés dans {link}.'
-tutorial.geometry.upload.notes.link: Gestion des ressources
+tutorial.geometry.upload.notes: 'Ajoutez {vertexBufferDispose} juste avant {swapChainDispose} dans le code de nettoyage à la fin de {programCs}.'
tutorial.geometry.upload.title: 'Allocation et transfert du tampon'
tutorial.input.description: 'Le GPU doit savoir où se trouvent les attributs de chaque sommet, comme la position et la couleur. La disposition d’entrée indique leur format et leur décalage, ainsi que le pas, la distance en octets entre deux sommets successifs. Ajoutez ce code après la création des shaders :'
tutorial.input.details: '{inputLayoutAdd} place chaque attribut immédiatement après le précédent et ajoute sa taille au pas entre sommets. Les décalages sont calculés à partir des formats fournis, sans examiner la structure C#. Pour ces deux champs, la disposition obtenue est la suivante :'
tutorial.input.guidance: 'La valeur par défaut de {semanticIndex} est zéro, ce qui correspond à {pOSITION0} et {cOLOR0} dans le shader. La position et la couleur étant stockées ensemble dans un seul tampon de sommets, le pipeline utilise une disposition d’entrée à l’emplacement 0. Cette disposition doit être adaptée si l’ordre des champs ou le remplissage de la structure C# change.'
-tutorial.input.table.headings.byteOffset: Décalage d’octets
+tutorial.input.table.headings.byteOffset: Décalage en octets
tutorial.input.table.headings.cField: 'Champ C#'
tutorial.input.table.headings.format: Format
tutorial.input.table.headings.shaderInput: Entrée de shader
@@ -413,43 +404,38 @@ tutorial.input.table.nextVertex.shaderInput: Enregistrement d’entrée suivant
tutorial.input.table.vertexColor.format: '{float4} (16 octets)'
tutorial.input.table.vertexPosition.format: '{float3} (12 octets)'
tutorial.input.title: 'Disposition des sommets en entrée'
-tutorial.lifecycle.description: 'Chaque image suit cette séquence :'
-tutorial.lifecycle.details: 'À la fermeture de la fenêtre, {run} retourne et l’exécution se poursuit avec le nettoyage. Chaque image ayant déjà attendu la fin de ses commandes, les ressources utilisées par ces commandes peuvent être libérées. Le nettoyage complet après {windowRun} est le suivant :'
+tutorial.lifecycle.description: 'Pour chaque image, l’application obtient la texture de sortie courante, la fait passer au layout nécessaire au rendu, l’efface et dessine le triangle. Elle la fait ensuite passer au layout de présentation, soumet les commandes, attend leur achèvement et présente l’image.'
+tutorial.lifecycle.details: 'À la fermeture de la fenêtre, {run} retourne et l’exécution se poursuit avec le nettoyage. Le rappel de rendu a déjà attendu la fin des commandes soumises pour chaque image ; les ressources utilisées par ces commandes peuvent donc être libérées. Le nettoyage complet après {windowRun} est le suivant :'
tutorial.lifecycle.guidance: 'Libérez la chaîne d’échange avant sa fenêtre native, et le contexte après ses ressources. La file recycle les tampons de commandes soumis, tandis que la chaîne d’échange gère sa texture de sortie. Aucun de ces objets ne nécessite donc d’appel distinct à {dispose}.'
-tutorial.lifecycle.title: 'Cycle d’image et libération'
tutorial.pipeline.behavior: 'Après la disposition d’entrée, créez le pipeline :'
-tutorial.pipeline.context: '{cullNone} désactive l’élimination des faces. Le triangle est donc dessiné que ses sommets apparaissent dans le sens horaire ou antihoraire.'
+tutorial.pipeline.context: '{cullNone} désactive l’élimination des faces. Le triangle est donc dessiné, que ses sommets soient disposés dans le sens horaire ou antihoraire.'
tutorial.pipeline.description: 'Un {graphicsPipeline} réunit la disposition des sommets, les deux shaders et les réglages d’assemblage des primitives et d’écriture dans les attachements.'
-tutorial.pipeline.details: 'Les shaders traitent les sommets et les fragments. Les autres réglages du pipeline contrôlent l’assemblage des primitives, l’élimination des faces, le test de profondeur et le mélange des couleurs :'
-tutorial.pipeline.guidance: 'Le format du pipeline doit correspondre à l’attachement ; il provient donc de {swapChainDescFormat}. {count1} indique un échantillon par pixel.'
+tutorial.pipeline.guidance: 'Le format de couleur du pipeline doit correspondre à celui de l’attachement de la passe ; il provient donc de {swapChainDescFormat}. {count1} indique un échantillon par pixel.'
tutorial.pipeline.item: '{triangleList} assemble chaque groupe de trois sommets consécutifs en un triangle.'
tutorial.pipeline.notes: '{depthNone} désactive le test et l’écriture de profondeur, puisque la passe ne comporte pas d’attachement de profondeur.'
tutorial.pipeline.reference: '{opaque} désactive le mélange. La couleur du fragment remplace ainsi le fond à l’intérieur du triangle.'
tutorial.pipeline.title: 'Pipeline graphique'
tutorial.pipeline.usage: 'Les objets shader peuvent être libérés après la création du pipeline. Conservez le pipeline pendant le rendu et ajoutez {pipelineDispose} avant {vertexBufferDispose} dans le nettoyage.'
tutorial.presentation.title: 'Contexte graphique et présentation'
-tutorial.project.context: 'Activez {emphasis} ({allowUnsafeBlocks}) dans les paramètres de compilation. Les appels natifs du code de fenêtre et le transfert des sommets nécessitent du code unsafe.'
+tutorial.project.context: 'Activez {emphasis} ({allowUnsafeBlocks}) dans les paramètres de compilation. Les appels natifs de la classe auxiliaire de fenêtre et le transfert des sommets nécessitent du code non sécurisé.'
tutorial.project.context.emphasis: Autoriser le code non sécurisé
tutorial.project.description: 'Créez un projet console C# nommé {firstTriangle} ciblant .NET 10.'
tutorial.project.details: 'Ajoutez les paquets NuGet suivants au projet :'
-tutorial.project.guidance: '{zenithNET} fournit l’API de rendu commune, et les trois paquets de backend en fournissent les implémentations propres aux plateformes. {zenithNETCompiler} compile les shaders Slang présentés plus bas pour le backend choisi. Silk.NET assure la création de la fenêtre et le traitement des événements.'
+tutorial.project.guidance: '{zenithNET} fournit l’API commune pour le rendu et le calcul ; les trois paquets propres aux API graphiques l’implémentent. {zenithNETCompiler} compile les shaders Slang pour l’API choisie.'
tutorial.project.title: 'Configuration du projet'
-tutorial.requirements.context: 'L’{link} et son {detail} fournissent les implémentations de référence de ce tutoriel.'
-tutorial.requirements.context.detail: hôte partagé
-tutorial.requirements.context.link: exemple Bonjour triangle
-tutorial.requirements.description: 'Vous devez disposer du {emphasis} et connaître les bases de C#. L’application cible {net10}. Le GPU et son pilote doivent prendre en charge le backend choisi pour votre plateforme :'
+tutorial.requirements.description: 'Vous devez disposer du {emphasis} et connaître les bases de C#. Le GPU et son pilote doivent prendre en charge les capacités graphiques suivantes selon la plateforme :'
tutorial.requirements.description.emphasis: SDK .NET 10
-tutorial.requirements.guidance: 'Zenith.NET rend dans une surface native fournie par l’application. Silk.NET.Windowing crée la fenêtre et gère les événements. Sous macOS, une couche Metal représentée par {cAMetalLayerCs} reçoit la sortie ; le code auxiliaire la rattache à la fenêtre.'
-tutorial.requirements.table.headings.graphicsBackend: Backend graphique
+tutorial.requirements.guidance: 'Zenith.NET effectue le rendu sur une surface native fournie par l’application. Silk.NET.Windowing crée la fenêtre et traite ses événements.'
+tutorial.requirements.table.headings.graphicsBackend: 'Prise en charge graphique'
tutorial.requirements.table.headings.platform: Plateforme
-tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 avec VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux (X11 ou XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: Metal 4
tutorial.requirements.table.macOS.platform: macOS
-tutorial.requirements.table.windows.graphicsBackend: DirectX 12
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 avec Shader Model 6.6'
tutorial.requirements.table.windows.platform: Windows
tutorial.requirements.title: 'Prérequis'
-tutorial.resize.context: 'Compilez et lancez de nouveau l’application. Le fond doit continuer à remplir la fenêtre lorsque vous la redimensionnez : chaque nouvelle passe ajuste son viewport et son rectangle de découpe aux dimensions de l’attachement. Conservez le rappel de rendu ; le triangle sera dessiné dans cette passe.'
+tutorial.resize.context: 'Compilez et lancez de nouveau l’application. Le fond doit continuer à remplir la fenêtre lorsque vous la redimensionnez. Conservez le rappel de rendu ; le triangle sera dessiné dans cette passe.'
tutorial.resize.description: 'La chaîne d’échange doit suivre les changements de dimensions du framebuffer. Ajoutez un gestionnaire de {framebufferResize} après le rappel de rendu et avant {windowRun} :'
tutorial.resize.details: 'Réagissez aux {link}, exprimés en pixels, plutôt qu’aux changements de taille logique de la fenêtre. Si la réduction de la fenêtre met l’une des dimensions du framebuffer à zéro, le gestionnaire de redimensionnement laisse la chaîne d’échange inchangée. Le rappel de rendu retourne lui aussi immédiatement tant qu’une dimension est nulle. Le rendu reprend lorsque le framebuffer retrouve des dimensions utilisables.'
tutorial.resize.details.link: 'changements de taille du framebuffer'
@@ -463,49 +449,31 @@ tutorial.shaders.compilation.description.emphasis: Copier dans le répertoire de
tutorial.shaders.compilation.details: 'Dans {programCs}, ajoutez l’initialisation des shaders après le transfert des sommets et avant le rappel de rendu :'
tutorial.shaders.compilation.guidance: '{zenithCompiler} compile le code source pour {contextGraphicsApi}, puis {createShader} crée un objet shader à partir de la description compilée. Les noms de points d’entrée {vSMain} et {fSMain} sélectionnent les deux fonctions définies dans le fichier Slang.'
tutorial.shaders.compilation.title: 'Compilation des shaders'
-tutorial.shaders.context: '{fSInput} relie les deux étapes de shader. Le shader de sommets écrit une position dans l’espace de clipping dans {sVPOSITION} ; le GPU s’en sert pour déterminer la partie visible du triangle. Le champ {cOLOR0} transmet la couleur du sommet, qui est interpolée sur le triangle avant de parvenir au shader de fragments. Son type et sa sémantique doivent correspondre entre les deux étapes.'
+tutorial.shaders.context: '{fSInput} relie les deux étapes de shader. Le shader de sommets écrit une position dans l’espace de découpage dans {sVPOSITION} ; le GPU s’en sert pour déterminer la partie visible du triangle. Le champ {cOLOR0} transmet la couleur du sommet, qui est interpolée sur le triangle avant de parvenir au shader de fragments. Son type et sa sémantique doivent correspondre entre les deux étapes.'
tutorial.shaders.description: 'Les shaders sont des programmes exécutés sur le GPU. Le shader de sommets détermine la position de chaque sommet ; le shader de fragments détermine la couleur aux emplacements de l’image couverts par le triangle. Les deux étapes seront écrites dans un même fichier Slang, chacune avec son point d’entrée, c’est-à-dire la fonction où commence son exécution.'
-tutorial.shaders.details: 'Créez {triangleSlang} avec ces structures d’entrée et de sortie :'
+tutorial.shaders.details: 'Créez {triangleSlang} à la racine du projet avec ces structures d’entrée et de sortie :'
tutorial.shaders.fragment.description: 'Ajoutez le point d’entrée de fragments dans le même fichier :'
tutorial.shaders.fragment.details: 'La rastérisation détermine les emplacements couverts par le triangle et y génère des fragments. Chaque fragment reçoit une couleur interpolée à partir des couleurs des trois sommets. {fSMain} renvoie cette couleur, et {sVTARGET} dirige le résultat vers le premier attachement de couleur.'
tutorial.shaders.fragment.title: 'Traitement des fragments'
tutorial.shaders.guidance: '{vSInput} définit l’entrée du shader de sommets. {pOSITION0} et {cOLOR0} identifient les attributs par leur sémantique ; les noms C# n’établissent pas cette correspondance.'
tutorial.shaders.title: 'Étapes des shaders'
tutorial.shaders.vertex.description: 'Ajoutez le point d’entrée de sommets à {triangleSlang} :'
-tutorial.shaders.vertex.details: 'Le GPU appelle ce point d’entrée pour chaque sommet, ajoute la coordonnée homogène {w} et transmet la couleur. La position est ensuite divisée par w. Ici w vaut 1 : x, y et z restent inchangés et correspondent aux coordonnées normalisées du périphérique.'
+tutorial.shaders.vertex.details: 'Le GPU exécute cette fonction pour chaque sommet en entrée. Elle complète la position avec une quatrième composante, {w}, et transmet la couleur. Après le traitement des sommets, le GPU divise x, y et z par w pour obtenir les coordonnées normalisées du périphérique. Avec w égal à 1, ces valeurs restent inchangées.'
tutorial.shaders.vertex.title: 'Traitement des sommets'
tutorial.surface.description: 'Définissez la cible de présentation native {emphasis} :'
tutorial.surface.description.emphasis: après {windowCenter} et avant {windowRun}
tutorial.surface.details: 'Le framebuffer est l’image de la fenêtre en pixels. {surface} décrit la cible de présentation native et ses dimensions ; {framebufferSize} donne la taille en pixels. Avec la mise à l’échelle de l’affichage, cette taille peut différer de la taille logique de la fenêtre.'
-tutorial.surface.guidance: 'La surface fournit les handles natifs du backend choisi : une fenêtre Win32 sous Windows, un affichage et une fenêtre X11 sous Linux, ou la couche Metal attachée sous macOS.'
+tutorial.surface.guidance: 'La description de la surface contient les handles natifs requis par l’API graphique choisie : une fenêtre Win32 sous Windows, un affichage et une fenêtre X11 sous Linux, ou la couche Metal attachée sous macOS.'
tutorial.surface.title: 'Surface native'
-tutorial.swapChain.context: 'La chaîne dépend du contexte et de la fenêtre. Remplacez {windowDispose} à la fin de {programCs} par cet ordre de libération :'
-tutorial.swapChain.description: 'Créez la chaîne d’échange immédiatement après la surface :'
-tutorial.swapChain.details: 'La {swapChain} gère les images présentées. {drawable} fournit l’image courante sous forme de {texture}, la ressource image de l’API. Après le rendu, {present} demande son affichage et passe à la suivante.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} stocke quatre canaux de 8 bits dans l’ordre bleu, vert, rouge, alpha. {uNorm} fait correspondre les entiers de 0 à 255 aux valeurs de 0 à 1. Le shader produit des valeurs RGBA ; le format détermine leur stockage en mémoire. Le pipeline reprend le format de couleur {swapChainDescFormat} pour correspondre à l’attachement.'
+tutorial.swapChain.context: 'La chaîne d’échange dépend du contexte et de la fenêtre. Remplacez {windowDispose} à la fin de {programCs} par cet ordre de libération :'
+tutorial.swapChain.description: 'Créez la chaîne d’échange immédiatement après la description de la surface :'
+tutorial.swapChain.details: 'La {swapChain} gère les images présentées par la fenêtre. {drawable} fournit l’image courante sous forme de {texture}, la ressource image de l’API. Après le rendu, {present} demande l’affichage de cette image et passe à la texture de sortie suivante.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} stocke quatre canaux de 8 bits dans l’ordre bleu, vert, rouge, alpha. {uNorm} fait correspondre les entiers de 0 à 255 aux valeurs de 0 à 1. Le shader produit des valeurs RGBA ; le format détermine leur stockage en mémoire.'
tutorial.swapChain.title: 'Chaîne d’échange'
tutorial.title: Premier triangle
-tutorial.troubleshooting.description: 'Les diagnostics console et les trois points de contrôle permettent d’isoler l’étape en échec :'
-tutorial.troubleshooting.details: 'Le {link} et le {detail} servent de référence pour les données des sommets, la disposition d’entrée et les commandes de dessin. Dans cet exemple, la fenêtre et la soumission sont gérées par un hôte commun ; ce tutoriel conserve le déroulement de l’application dans {programCs}. L’exemple {context} introduit le dessin indexé, les transformations et le test de profondeur.'
-tutorial.troubleshooting.details.context: Cube en rotation
-tutorial.troubleshooting.details.detail: shader Slang
-tutorial.troubleshooting.details.link: moteur de rendu d’exemple
-tutorial.troubleshooting.table.backend.check: Vérifiez que le backend sélectionné est pris en charge par l’appareil et le pilote graphique installé.
-tutorial.troubleshooting.table.backend.symptom: La création du backend échoue
-tutorial.troubleshooting.table.drawing.check: Vérifiez la taille du transfert, l’agencement d’entrée, la sélection du pipeline et le placement des commandes de dessin à l’intérieur de la passe de rendu.
-tutorial.troubleshooting.table.drawing.symptom: L’arrière-plan apparaît mais pas le triangle
-tutorial.troubleshooting.table.headings.check: Vérification
-tutorial.troubleshooting.table.headings.symptom: Symptôme
-tutorial.troubleshooting.table.input.check: 'Vérifiez le pas de 28 octets et les décalages de la position et de la couleur : respectivement 0 et 12 octets.'
-tutorial.troubleshooting.table.input.symptom: Les positions ou les couleurs des sommets sont corrompues
-tutorial.troubleshooting.table.shaders.check: Vérifiez le fichier {triangleSlang} copié, l’orthographe du point d’entrée et le diagnostic signalé par le compilateur.
-tutorial.troubleshooting.table.shaders.symptom: 'Le fond s’affiche, mais le chargement des shaders échoue'
-tutorial.troubleshooting.table.window.check: Confirmez que le projet .NET se compile et que l’étape de fenêtre seule s’exécute dans une session de bureau. Sous Linux, vérifiez que X11 ou XWayland est disponible.
-tutorial.troubleshooting.table.window.symptom: Aucune fenêtre ne s’ouvre
-tutorial.troubleshooting.title: 'Diagnostic des erreurs'
tutorial.window.description: 'Téléchargez {cocoaHelperCs} dans le projet. Cette classe auxiliaire attache la couche Metal à la fenêtre macOS.'
-tutorial.window.details: 'Remplacez le contenu généré de {programCs} par le code suivant. Les instructions de niveau supérieur s’exécutent dans l’ordre, sans méthode {main} explicite. Les prochaines sections préciseront où ajouter chaque extrait :'
-tutorial.window.guidance: '{graphicsAPINone} laisse à Zenith.NET la création du contexte graphique. {initialize} crée la fenêtre native et rend ses handles disponibles. {center} la place au centre de l’écran. {run} traite les événements jusqu’à sa fermeture, puis l’exécution passe à {dispose} pour la libérer.'
+tutorial.window.details: 'Remplacez le contenu de {programCs} par le code suivant :'
+tutorial.window.guidance: '{graphicsAPINone} empêche Silk.NET de créer son propre contexte graphique pour la fenêtre ; l’application créera ensuite un contexte Zenith.NET. {initialize} crée la fenêtre native et rend ses handles disponibles. {center} la place au centre de l’écran. {run} traite les événements jusqu’à sa fermeture, puis {dispose} libère la fenêtre.'
tutorial.window.notes: 'Compilez et lancez l’application. Vérifiez que la fenêtre s’ouvre et se ferme correctement, et que vous pouvez la déplacer et la redimensionner. Son contenu n’est pas encore défini, car aucune commande de rendu n’a été soumise. Fermez la fenêtre avant de poursuivre.'
tutorial.window.title: 'Création de la fenêtre'
ui.action.copy: Copier
@@ -525,7 +493,7 @@ ui.api.noNamespaceTypes: Aucun type dans cet espace de noms.
ui.api.noTypes: Aucun type correspondant.
ui.api.types: Types
ui.content.reference: Référence
-ui.content.source: Code source
+ui.content.examples: Exemples de code
ui.content.tutorial: Tutoriel
ui.contents.close: Fermer la table des matières
ui.contents.open: Ouvrir la table des matières
@@ -547,7 +515,7 @@ ui.navigation.concepts: Concepts
ui.navigation.home: Accueil
ui.navigation.label: Navigation principale
ui.navigation.skip: Aller au contenu
-ui.navigation.toggle: Basculer la navigation
+ui.navigation.toggle: Afficher ou masquer la navigation
ui.outline.title: Sur cette page
ui.reference.assembly: Assembly
ui.reference.classes: Classes
@@ -562,14 +530,13 @@ ui.reference.exceptions: Exceptions
ui.reference.extensionMethods: Méthodes d’extension
ui.reference.fields: Champs
ui.reference.implementations: Implémentations explicites d’interface
-ui.reference.implements: Implémente
ui.reference.inheritance: Héritage
ui.reference.inheritedMembers: Membres hérités
ui.reference.interfaces: Interfaces
ui.reference.metadata: Métadonnées du type
ui.reference.methods: Méthodes
ui.reference.namespace: Espace de noms
-ui.reference.open: Ouvrir la référence pour {name}
+ui.reference.open: Consulter la référence de {name}
ui.reference.operators: Opérateurs
ui.reference.parameters: Paramètres
ui.reference.properties: Propriétés
@@ -583,7 +550,7 @@ ui.reference.value: Valeur
ui.reference.values: Valeurs
ui.search.close: Fermer la recherche
ui.search.empty: Aucun résultat pour « {query} ».
-ui.search.hint: Recherchez dans les tutoriels, concepts, exemples et la référence de l’API.
+ui.search.hint: Recherchez dans les tutoriels, les concepts, les exemples et la référence de l’API.
ui.search.loading: Chargement de la recherche…
ui.search.more: Afficher plus de résultats
ui.search.pending: Recherche en cours…
diff --git a/documents/locales/fr-FR/translation.md b/documents/locales/fr-FR/translation.md
index fa9f17f4..10e5c006 100644
--- a/documents/locales/fr-FR/translation.md
+++ b/documents/locales/fr-FR/translation.md
@@ -74,6 +74,8 @@ Avant livraison, vérifier les clés et les espaces réservés. Contrôler l’a
| command queue | file de commandes |
| drawable | texture de sortie de l’image en cours de rendu ; conserver `Drawable`, sans supposer qu’elle appartient à une chaîne d’échange |
| graphics context | contexte graphique |
+| graphics API | API graphique ; DirectX 12, Metal 4 ou Vulkan 1.4 |
+| implementation | implémentation de l’API graphique ; pour les différences techniques entre implémentations |
| pipeline | pipeline |
| readback | lecture de données depuis le GPU |
| render pass | passe de rendu |
diff --git a/documents/locales/ja-JP/strings.yml b/documents/locales/ja-JP/strings.yml
index 3ee356f9..7d67c9dc 100644
--- a/documents/locales/ja-JP/strings.yml
+++ b/documents/locales/ja-JP/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: '{graphicsContext} は特定のバックエンドを介してアプリケーションを GPU デバイスに接続し、描画、計算、転送のキューを提供します。一緒に使うリソースは同じコンテキストに属している必要があります。バッファー、テクスチャ、シェーダー、パイプラインとそのハンドルを、コンテキストをまたいでバインドすることはできません。'
+concepts.execution.context.description: '{graphicsContext} は選択したグラフィックス API を通じてアプリケーションを GPU デバイスに接続し、描画、計算、転送のキューを提供します。一緒に使うリソースは同じコンテキストに属している必要があります。バッファー、テクスチャ、シェーダー、パイプラインとそのハンドルを、コンテキストをまたいでバインドすることはできません。'
concepts.execution.context.details: '{capabilities} はデバイス名と対応機能を提供します。レイトレーシングやメッシュシェーディング用のリソースを作成する前に、{rayTracingSupported} と {meshShadingSupported} で対応を確認します。{link}と{detail}のサンプルでは、初期化時にこの確認を行っています。'
concepts.execution.context.details.detail: 'メッシュシェーディング'
concepts.execution.context.details.link: 'レイトレーシング'
@@ -15,7 +15,7 @@ concepts.execution.ownership.table.commandBuffers.object: '借用したコマン
concepts.execution.ownership.table.commandBuffers.ownership: 'キューが管理して再利用します。'
concepts.execution.ownership.table.headings.object: 'オブジェクト'
concepts.execution.ownership.table.headings.ownership: '解放の責任'
-concepts.execution.ownership.table.queues.object: 'コンテキストキューとそのタイムライン'
+concepts.execution.ownership.table.queues.object: 'コンテキストのキューとそのタイムライン'
concepts.execution.ownership.table.queues.ownership: 'コンテキストとキューが管理します。'
concepts.execution.ownership.table.swapChainDrawable.ownership: 'スワップチェーンが管理します。'
concepts.execution.ownership.title: '所有権と寿命'
@@ -26,10 +26,10 @@ concepts.execution.pipelines.guidance.detail: 'コンピュートサンプル'
concepts.execution.pipelines.guidance.link: '三角形の描画コールバック'
concepts.execution.pipelines.title: 'パイプラインの状態'
concepts.execution.queues.description: '描画、計算、コピーを含むフレームでは、通常は {graphicsQueue} から始めます。依存する操作を同じキューにまとめると、順序を扱いやすくなります。'
-concepts.execution.queues.details: '独立した処理を別々のキューに送信できますが、各キューが独立したハードウェア実行ユニットに対応するとは限りません。処理を並行して実行する利点がある場合に、キューを追加します。一方のキューがもう一方の生成データを使う場合は、送信間に明示的な依存関係を設定します。'
+concepts.execution.queues.details: '独立した処理を重ねて実行できる場合は、追加のキューが役立ちます。ただし、キューごとに独立したハードウェア実行ユニットがあるとは限りません。一方のキューがもう一方の生成データを使う場合は、送信間に明示的な依存関係を設定します。'
concepts.execution.queues.guidance: '同じキュー内でも、依存する操作にはバリアやテクスチャ遷移が必要になる場合があります。後のアクセスで、それ以前の書き込み結果を読み取れるようにするためです。このメモリ依存関係は送信順序とは別の要件であり、指定方法は{link}で説明します。'
concepts.execution.queues.guidance.link: '同期'
-concepts.execution.queues.table.computeQueue.workToRecord: 'コンピュートディスパッチと対応する転送操作。グラフィックスのレンダーパスは含みません。'
+concepts.execution.queues.table.computeQueue.workToRecord: 'コンピュートディスパッチと、このキューで扱える転送操作。グラフィックスのレンダーパスは含みません。'
concepts.execution.queues.table.graphicsQueue.workToRecord: 'レンダーパス、描画、計算、転送の操作。'
concepts.execution.queues.table.headings.queue: 'キュー'
concepts.execution.queues.table.headings.workToRecord: '対応する操作'
@@ -41,18 +41,16 @@ concepts.execution.recording.details: '三角形のチュートリアルでは
concepts.execution.recording.guidance: '記録によってコマンド列を構築し、{submit} でその実行をスケジュールします。続いて {wait} を呼ぶと、送信した処理が完了するまで CPU スレッドが待機します。チュートリアルでは次のフレームを始める前に現在のフレームが終わるため、処理の順序を追いやすくなります。'
concepts.execution.recording.title: '記録と送信'
concepts.execution.title: '実行モデル'
-concepts.platforms.description: '画面への提示は、アプリケーションまたは UI コントロールが管理します。この選択によって、フレームの出力テクスチャを取得し、コマンドを記録・送信して結果を提示する担当が決まります。この出力テクスチャを drawable と呼びます。'
-concepts.platforms.frame.context: 'パス内でパイプラインのバインドと描画を記録し、ハンドラーから戻る前にパスを終了します。コントロールがコマンドを送信し、結果を提示します。ハンドラーでは送信を行わず、渡されたコマンドバッファーや drawable を解放しないでください。drawable のレイアウトを変更した場合は、コントロールが最後の遷移を行えるよう、戻る前に {colorAttachment} に戻します。'
+concepts.platforms.description: '画面への提示は、アプリケーションまたは UI の描画コントロールが管理します。この選択によって、フレームの出力テクスチャを取得し、コマンドを記録・送信して結果を提示する担当が決まります。この出力テクスチャを drawable と呼びます。'
+concepts.platforms.frame.context: 'パス内でパイプラインのバインドと描画を記録し、ハンドラーから戻る前にパスを終了します。ハンドラーでは送信を行わず、渡されたコマンドバッファーや drawable を解放しないでください。drawable のレイアウトを変更した場合は、コントロールが最後の遷移を行えるよう、戻る前に {colorAttachment} に戻します。'
concepts.platforms.frame.description: 'コントロールは {iZenithView} を実装します。アプリケーションは {graphicsContext} を設定し、{updateRequested} でシーンを更新し、{renderRequested} で渡された {renderEventArgs} を使ってコマンドを記録します。'
concepts.platforms.frame.details: '各フレームで、コントロールは drawable とコマンドバッファーを取得し、drawable を {colorAttachment} に遷移させてから、更新と描画のハンドラーを呼びます。その後、記録した処理を送信し、フレームワークの提示方式に従って画像を表示します。'
concepts.platforms.frame.guidance: 'ファイルに {usingZenithNET} を追加します。{view} という名前の {iZenithView} が初期化され、グラフィックスコンテキストも設定済みなら、次のハンドラーで drawable をクリアできます。'
concepts.platforms.frame.notes: '最初の遷移は {undefined} を使うため、以前の画像内容は破棄できます。毎フレーム、画像全体を描画するかクリアしてください。蓄積する描画結果やキャッシュはアプリケーション所有のテクスチャに保存し、そのテクスチャをコントロールの drawable に描画します。'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} は、これらの統合で使う既定のカラーフォーマットを提供します。'
concepts.platforms.frame.title: 'UI コントロールでの描画'
concepts.platforms.integration.context: 'WinForms、WPF、Windows 向け WinUI の統合は Windows 上で動作します。MAUI では対象プラットフォームのワークロードをインストールし、{extensionsCs} のように {useZenithView} でコントロールハンドラーを登録します。'
concepts.platforms.integration.description: 'イベントのインターフェースは共通ですが、提示方式はフレームワークごとに異なります。'
-concepts.platforms.integration.details: 'GPU の画像を UI に届ける方法は、実装によって異なります。ビットマップへのリードバックでは、表示前にピクセルを CPU メモリへコピーします。共有テクスチャの相互運用では、この CPU コピーを省けますが、GPU コピーや同期が必要な場合があります。統合を選ぶ際は、共通の {renderRequested} イベントだけでなく、提示方法も検討してください。'
-concepts.platforms.integration.guidance: '使用する UI フレームワークの統合パッケージを NuGet から追加します。Avalonia では {avaloniaPackage} を使います。'
+concepts.platforms.integration.details: 'UI 統合によって、GPU の画像を画面に渡す方法が異なります。ビットマップへのリードバックでは、表示前にピクセルを CPU メモリへコピーします。共有テクスチャの相互運用では CPU へのコピーを省けますが、GPU コピーや同期が必要な場合もあります。共通の {renderRequested} イベントだけでなく、提示方式も考慮してください。'
concepts.platforms.integration.table.avalonia.integration: 'Avalonia'
concepts.platforms.integration.table.avalonia.presentation: 'テクスチャにレンダリングし、ピクセルを {writeableBitmap} にリードバックします。{zenithViewCs} および {surfaceCs} を参照してください。'
concepts.platforms.integration.table.headings.integration: '統合'
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: '提示方式'
concepts.platforms.integration.table.maui.integration: '.NET MAUI'
concepts.platforms.integration.table.maui.presentation: 'Android、iOS、Mac Catalyst ではネイティブサーフェスを使用し、Windows では共有テクスチャコンポジションを使用します。{link} を参照してください。'
concepts.platforms.integration.table.maui.presentation.link: 'プラットフォーム実装'
-concepts.platforms.integration.table.uno.integration: 'Uno パス'
+concepts.platforms.integration.table.uno.integration: 'Uno Platform'
concepts.platforms.integration.table.uno.presentation: 'ピクセルを {writeableBitmap} にリードバックします。{zenithViewUnoCs} を参照してください。'
concepts.platforms.integration.table.winForms.integration: 'WinForms'
concepts.platforms.integration.table.winForms.presentation: 'コントロールの {hWND} 用に Zenith.NET スワップチェーンを作成します。{zenithViewCs} を参照してください。'
@@ -76,16 +74,16 @@ concepts.platforms.lifecycle.guidance: 'アプリケーションの深度テク
concepts.platforms.lifecycle.guidance.link: '回転する立方体のレンダラー'
concepts.platforms.lifecycle.title: 'スワップチェーンの寸法と寿命'
concepts.platforms.ownership.description: '設定したコンテキストと描画リソースはアプリケーションが、提示用リソースはコントロールが所有します。ビューの {graphicsContext} を変えると、スケジューラーは新しいコンテキストでコントロールのリソースを再作成します。アプリケーションのパイプライン、バッファー、テクスチャも、同じコンテキストで作り直してください。'
-concepts.platforms.ownership.details: '描画リソースを置き換える前にビューのフレーム処理を止め、そのリソースを使う GPU 処理の完了を待ちます。その後、古いリソースやコンテキストを解放します。ビューを削除した場合も、設定したコンテキストの解放はアプリケーションが担当します。'
+concepts.platforms.ownership.details: '描画リソースを置き換える前にビューのフレームループを止め、そのリソースを使う GPU 処理の完了を待ちます。その後、古いリソースを解放します。コンテキストを解放できるのは、すべてのビューがそのコンテキスト用の提示リソースを解放し、そのコンテキストから作成したアプリケーションのリソースもすべて解放した後です。'
concepts.platforms.ownership.guidance: '共通の {frameSchedulerCs} は、ビューの UI ディスパッチャーを通してフレームハンドラーを実行します。ハンドラーはシーンデータの更新とコマンドの記録に集中させてください。そこで長い CPU 処理を行うと、UI の応答も遅れます。'
concepts.platforms.ownership.title: 'アプリケーションとコントロールの所有権'
concepts.platforms.surface.description: '{link}では、Silk.NET がウィンドウを作成してイベントを処理します。Zenith.NET は {surface} 記述を通じてネイティブウィンドウのハンドルと寸法を受け取り、それを使って {swapChain} を作成します。OS のウィンドウは引き続きアプリケーションが管理します。'
concepts.platforms.surface.description.link: '三角形のチュートリアル'
-concepts.platforms.surface.details: 'サーフェスのハンドルはバックエンドと対応させます。'
+concepts.platforms.surface.details: 'サーフェスに渡すハンドルは、グラフィックス API とウィンドウシステムによって異なります。主な組み合わせは次のとおりです。'
concepts.platforms.surface.guidance: '{appCs} のサンプルホストは Windows、macOS、X11 に対応しています。Linux のウィンドウは Xlib ハンドルを渡すため、Wayland セッションで実行するには XWayland が必要です。ネイティブ Wayland アプリケーションでは、{surfaceWayland} にディスプレイとサーフェスのハンドルを渡します。'
concepts.platforms.surface.table.android.backend: 'Android 上の Vulkan。'
concepts.platforms.surface.table.apple.backend: 'Apple プラットフォーム上の Metal。'
-concepts.platforms.surface.table.headings.backend: 'バックエンドとプラットフォーム'
+concepts.platforms.surface.table.headings.backend: 'グラフィックス API とプラットフォーム'
concepts.platforms.surface.table.headings.factory: 'サーフェスファクトリ'
concepts.platforms.surface.table.headings.handles: 'ホストから提供されるハンドル'
concepts.platforms.surface.table.wayland.backend: 'ネイティブ Wayland ホストを使用した Vulkan。'
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'ネイティブの提示サーフェス'
concepts.platforms.title: 'プラットフォーム統合'
concepts.resources.allocation.context: 'ヒープに配置したリソースは、その寿命全体にわたってヒープの記憶領域を使います。最後の GPU 使用が終わったら、リソースを先に解放し、その後ヒープを解放します。'
concepts.resources.allocation.description: 'アプリケーションでメモリ割り当てを管理する場合は、{heap} を使います。ヒープは、指定したバイトオフセットにリソースを配置する記憶領域です。オフセットの選択と使用領域の管理はアプリケーションが行います。'
-concepts.resources.allocation.details: '各リソースの作成に使うバッファーまたはテクスチャ記述を渡して、{contextGetSizeAndAlignment} を呼びます。返されたアラインメントの倍数となるオフセットに、返されたサイズ分の領域を確保します。領域はヒープ内に収め、使用中の別の割り当てと重ねてはいけません。テクスチャにはバックエンド固有のパディングが含まれる場合があるため、ピクセル数とピクセル当たりのバイト数だけでは割り当てサイズを算出できません。'
+concepts.resources.allocation.details: '各リソースの作成に使うバッファーまたはテクスチャ記述を渡して、{contextGetSizeAndAlignment} を呼びます。返されたアラインメントの倍数となるオフセットに、返されたサイズ分の領域を確保します。領域はヒープ内に収め、使用中の別の割り当てと重ねてはいけません。テクスチャにはパディングが含まれる場合があるため、ピクセル数とピクセル当たりのバイト数だけでは割り当てサイズを算出できません。'
concepts.resources.allocation.guidance: 'ヒープに配置するバッファーは、そのヒープと同じ常駐区分を指定します。テクスチャの格納には GPU 専用ヒープを使います。'
concepts.resources.allocation.title: 'ヒープへの配置'
concepts.resources.bufferUsages.table.constant.role: '定数バッファーバインドを介して読み取られるシェーダーパラメーター。'
@@ -110,10 +108,10 @@ concepts.resources.bufferUsages.table.storageReadOnly.role: '読み取り専用
concepts.resources.bufferUsages.table.storageReadWrite.role: '読み書き可能なシェーダーバインドを介してアクセスするバッファーデータ。'
concepts.resources.bufferUsages.table.transferDst.role: 'GPU コピーの転送先ストレージ。'
concepts.resources.bufferUsages.table.transferSrc.role: 'GPU コピーの転送元データ。'
-concepts.resources.bufferUsages.table.vertex.role: '描画のためにフェッチされる頂点属性。'
+concepts.resources.bufferUsages.table.vertex.role: '描画のために読み取られる頂点属性。'
concepts.resources.bufferUsages.title: 'バッファーの用途'
concepts.resources.description: 'リソース記述は、アプリケーションが記憶領域をどう使えるかを定めます。例えば、描画先にし、シェーダーでサンプリングし、CPU に読み戻すテクスチャには、三つの操作に対応する用途フラグが必要です。メモリ配置は CPU のアクセス方法を決めます。データにアクセスできる時点や記憶領域を解放できる時点は、同期と寿命の管理によって決まります。'
-concepts.resources.memory.context: 'CPU からアクセスできるバッファーでは、{map} がデータを読み書きするためのアドレスを提供します。マッピングも {unmap} も、GPU の処理を待機しません。GPU が書いた結果を CPU で読む前にはその書き込みを待ち、同じバイトを書き換える前には、その領域への GPU アクセスが終わるのを待ちます。'
+concepts.resources.memory.context: 'CPU からアクセスできるバッファーでは、{map} がデータを読み書きするためのアドレスを提供します。マッピングも {unmap} も、GPU の処理が完了するのを待ちません。GPU が書いた結果を CPU で読む前にはその書き込みの完了を待ち、同じバイトを書き換える前には、その領域への GPU アクセスが終わるのを待ちます。'
concepts.resources.memory.description: '{bufferDesc} の {residency} は、想定する CPU アクセスを指定します。'
concepts.resources.memory.details: '常駐区分は CPU アクセスの要件を表します。CPU と GPU が物理メモリを共有するシステムでも、この区分を使います。三角形では {cpuWriteOnly} を使い、小さな頂点バッファーを直接初期化します。大きな静的ジオメトリでは、GPU 専用の記憶領域へアップロードする方が適している場合があります。'
concepts.resources.memory.guidance: 'コンテキストから直接作成したテクスチャは GPU の記憶領域を使うため、{textureDesc} に常駐区分のフィールドはありません。CPU メモリとのデータ交換には、アップロードとリードバックを使います。'
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: 'アップロードは CPU データ
concepts.resources.transfers.details: '呼び出す前に、他のキューとの競合するアクセスを解消します。メソッド内の待機は自身の転送だけを対象とし、他のキューとの依存関係を設定するものではありません。マッピングしたメモリを直接コピーする場合は、競合する GPU アクセスの完了を呼び出し側で待つ必要があります。'
concepts.resources.transfers.guidance: '他の GPU 処理とまとめて転送を送信するには、{commandBufferUpload} または {commandBufferDownload} で記録します。アップロードの転送元とリードバックの転送先では、メモリを有効に保つ必要のある期間が異なります。'
concepts.resources.transfers.item: 'アップロードの呼び出し中に、ライブラリは元データをステージングメモリと呼ばれる内部の一時領域へコピーします。GPU は後でこの領域を読むため、アプリケーションの元ポインターが必要なのは、呼び出しが戻るまでです。'
-concepts.resources.transfers.notes: 'テクスチャ転送の行ストライドは、CPU データの隣り合う行の間隔をバイトで表します。スライスストライドは、深さ方向に隣り合うスライスの間隔です。転送処理はこれらの値を使い、CPU データとテクスチャの GPU 記憶領域との間でコピーします。GPU の完了と宛先へのコピーが別の段階になる理由は、{link}で説明します。'
-concepts.resources.transfers.notes.link: '同期'
+concepts.resources.transfers.layouts: 'コマンドバッファーに記録するテクスチャ転送には、レイアウト遷移は含まれません。アップロードには {copyDst}、リードバックには {copySrc} が必要です。コピーの前にこれらのレイアウトへの遷移を記録し、コピーの後に次の用途が必要とするレイアウトへの遷移を記録します。'
+concepts.resources.transfers.notes: 'テクスチャ転送の行ストライドは、CPU データの隣り合う行の間隔をバイトで表します。スライスストライドは、深さ方向に隣り合うスライスの間隔です。転送処理はこれらの値を使い、CPU データとテクスチャの GPU 記憶領域との間でコピーします。'
concepts.resources.transfers.table.bufferDownload.transfer: '{cpuReadOnly} では、マッピングしたメモリから直接コピーします。それ以外は転送キューにリードバックを送信し、完了を待ちます。'
concepts.resources.transfers.table.bufferUpload.transfer: '{cpuWriteOnly} では、マッピングしたメモリへ直接コピーします。それ以外は転送キューにアップロードを送信し、完了を待ちます。'
concepts.resources.transfers.table.headings.method: '方法'
concepts.resources.transfers.table.headings.transfer: '転送の動作'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'コピーとテクスチャ遷移をグラフィックスキューに送信し、完了を待ちます。終了時には、選択したサブリソースが指定した最終レイアウトになります。'
-concepts.resources.transfers.title: '即時転送とコマンドへの記録'
+concepts.resources.transfers.title: '即時転送とコマンドバッファーによる転送'
concepts.resources.usages.description: '{bufferUsages} と {textureUsages} は、リソースの用途を宣言するフラグ列挙型です。それぞれ {bufferDescUsages} と {textureDescUsages} に設定します。複数の用途には、必要なメンバーを {value} で組み合わせます。'
concepts.resources.usages.title: 'リソースの用途'
-concepts.resources.views.description: '{bufferView} はバッファーの範囲とデータの解釈方法を記述します。{textureView} はサブリソース範囲と、互換性のあるテクスチャ種別やフォーマットを選択します。どちらも既存の記憶領域を参照し、その作成時に宣言した用途に従います。ビューの範囲はアクセス範囲を示すものであり、シェーダーの境界検査が全バックエンドで同じように働くことを保証するものではありません。'
+concepts.resources.views.description: '{bufferView} はバッファーの範囲とデータの解釈方法を記述します。{textureView} はサブリソース範囲と、互換性のあるテクスチャ種別やフォーマットを選択します。どちらも既存の記憶領域を参照し、その作成時に宣言した用途に従います。ビューの範囲はアクセス範囲を示しますが、シェーダーで一貫した境界検査が行われることは保証しません。'
concepts.resources.views.details: 'リソース自身のハンドルは既定のビューを提供します。別の範囲や互換性のある解釈方法を選ぶ場合は、独立したビューを作成します。ビューと元リソースはどちらも、GPU が使い終わるまで保持してください。ハンドルだけでは、どちらのオブジェクトも保持されません。いずれかを置き換えたら、古い{link}を含む定数も更新します。'
concepts.resources.views.details.link: 'リソースハンドル'
concepts.resources.views.title: 'ビューと参照先リソース'
concepts.shaders.binding.context: 'コンピュートのサンプルでは、{input} に {inputTextureSampledHandle}、{output} に {outputTextureStorageHandle} を設定します。Slang の {descriptorHandle} の型引数が、各リソースへのアクセス方法を定めます。'
concepts.shaders.binding.description: '{setConstantBuffer} は、現在のパイプラインが定数を読み取るバッファーとバイトオフセットを選択します。シェーダーが使う前に、パラメーターのデータをその領域へアップロードします。以前の GPU 処理が同じ領域をまだ読んでいる場合は、完了を待ってから更新してください。'
concepts.shaders.binding.details: 'コマンドバッファー、コンピュートパイプライン、データを設定した定数バッファー、スレッドグループ数が用意できたら、次の順にディスパッチを記録します。定数バッファーは選択中のパイプラインにバインドされるため、先にパイプラインを選択します。'
-concepts.shaders.binding.guidance: 'ここでは {commandBuffer} に、{computePipeline} と {constantBuffer} のパラメーターを使うディスパッチを記録しています。定数バッファーには {bufferUsagesConstant} の用途が必要で、オフセット 0 はその先頭を指定します。一つのバッファーを複数の定数レコードで共有する場合、各開始オフセットはバックエンドのバインド時アラインメント要件にも従います。これは、レコード内部のフィールド配置とは別の要件です。'
-concepts.shaders.binding.notes: '{resourceHandle} は二つの 32 ビットフィールドを持ち、解釈はバックエンドに依存します。値はリソースを作成したコンテキスト内でのみ有効です。'
+concepts.shaders.binding.guidance: '定数バッファーには {bufferUsagesConstant} の用途が必要です。一つのバッファーを複数の定数レコードで共有する場合、各レコードの開始オフセットはバインド時に要求されるアラインメントを満たす必要があります。これはレコード内部のフィールド配置とは別の要件です。'
+concepts.shaders.binding.notes: '{resourceHandle} は二つの 32 ビットフィールドを持ち、解釈はグラフィックス API によって異なります。値はリソースを作成したコンテキスト内でのみ有効です。'
concepts.shaders.binding.reference: 'ハンドルの取得元リソースとビューは、シェーダーの最後のアクセスが完了するまで保持します。テクスチャやビューの置換後は、古いハンドルを含む定数を更新してください。所有権の規則は{link}で説明します。'
concepts.shaders.binding.reference.link: 'リソース管理'
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'シェーダー型 {t} の構造化要素の読み取り'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: 'テクスチャのサン
concepts.shaders.binding.table.textureSampledHandle.access: 'テクスチャの読み取り'
concepts.shaders.binding.table.textureStorageHandle.access: 'ストレージテクスチャの読み書き'
concepts.shaders.binding.title: '定数バッファーとリソースハンドル'
-concepts.shaders.compilation.description: '{zenithCompiler} は Slang の指定エントリーポイントを {shaderDesc} にコンパイルします。コンテキストの {graphicsApi} に応じ、DirectX 12 には DXIL、Metal には Metal ライブラリ、Vulkan には SPIR-V を生成します。'
+concepts.shaders.compilation.description: '{zenithCompiler} は Slang のエントリーポイントをコンパイルし、{shaderDesc} を返します。コンテキストの {graphicsApi} によって出力形式が決まり、DirectX 12 は {dxil}、Metal は {metallib}、Vulkan は {spirv} です。'
concepts.shaders.compilation.details: '{context} という名前のグラフィックスコンテキストを作成してから、実行ファイルと同じディレクトリにコピーした三角形のシェーダーをコンパイルします。'
concepts.shaders.compilation.guidance: 'エントリーポイント名 {vSMain} は、シェーダーファイル内の宣言と一致させます。シェーダーのコンパイルとパイプラインの作成は初期化時に行い、描画中はパイプラインを再利用します。作成が終われば、{link}で示すようにシェーダーオブジェクトを解放できます。'
concepts.shaders.compilation.guidance.link: '最初の三角形'
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: '頂点入力の {inputLayout} は、各属
concepts.shaders.layout.details: '定数バッファーはシェーダーのパラメーターを、構造化バッファーは型付き要素の配列を格納します。これらの配置は {inputLayout} ではなく、Slang の宣言に従います。C# のフィールドオフセット、要素サイズ、パディングを、コンパイル済みシェーダーの配置に合わせてください。C# のアンマネージ型はバイト列としてコピーできますが、そのメモリ配置がシェーダーの配置と一致するとは限りません。頂点内で密に格納した {float3} も、シェーダーバッファーでは別のアラインメントが必要になる場合があります。'
concepts.shaders.layout.guidance: 'シェーダーのパラメーターには、数値とともにリソースハンドルを含められます。ハンドルは既存の記憶領域を指すため、定数バッファーにコピーしてもリソースの内容はコピーされません。'
concepts.shaders.layout.notes: '{computeShaderSlang} の対応する宣言は次のとおりです。'
-concepts.shaders.layout.reference: '二つの寸法値が先頭の 8 バイトを占め、その後に二つの 8 バイトのハンドルが続きます。C# サンプルはレコード全体に 256 バイトを確保します。別のレコードでは、フィールドの内容と必要な配置、アラインメントからサイズを決めます。'
+concepts.shaders.layout.reference: 'C# のフィールドは先頭の 24 バイトを占めます。寸法値に合計 8 バイト、各ハンドルに 8 バイトを使います。256 バイトのレコードの残りはパディングです。別のパラメーターブロックでは、フィールドオフセットをシェーダーの配置に合わせてください。複数のレコードでバッファーを共有する場合は、各開始位置が要求されるバインド時アラインメントを満たすよう、レコード間にも十分なパディングを設けます。'
concepts.shaders.layout.title: 'データ配置'
concepts.shaders.matrices.description: 'コンパイラーは行ごとに連続する行優先の行列配置を選択します。{link}では三つの {matrix4x4} をオフセット 0、64、128 に格納します。対応する{detail}では、{mulVectorMatrix} をモデル、ビュー、投影の順に適用します。'
concepts.shaders.matrices.description.detail: 'シェーダー'
@@ -201,24 +199,24 @@ concepts.shaders.matrices.description.link: '回転する立方体のレンダ
concepts.shaders.matrices.details: '格納順序はメモリ内の行列要素の配置を、乗算順序は変換を定めます。C# と Slang で対応する規約を使います。'
concepts.shaders.matrices.title: '行列の規約'
concepts.shaders.title: 'シェーダーデータとバインド'
-concepts.synchronization.backends.description: 'DirectX 12 と Vulkan は、テクスチャ遷移をレイアウトとアクセスの変更として記録します。Zenith.NET の Metal バックエンドでは、{transition} に相当する GPU 操作はありません。代わりにコマンドを描画・計算エンコーダーにまとめ、エンコーダー終了時に可視性バリアを挿入します。連続するコンピュートディスパッチなど、同じエンコーダー内の依存には明示的な {barrier} 呼び出しを使います。'
-concepts.synchronization.backends.details: '{link}では、グラフィックスのレンダーパスを開始すると計算エンコーダーが終了し、計算結果を描画処理から読み取れるようになります。連続する二つのコンピュートディスパッチは同じエンコーダー内にとどまるため、間にテクスチャ遷移を記録しても、依存を指定するバリアが必要です。このため、複数のバックエンドで使うコマンド列では、レイアウトとアクセス依存の両方を扱います。'
+concepts.synchronization.backends.description: 'DirectX 12 と Vulkan は、テクスチャ遷移をレイアウトとアクセスの変更として記録します。Zenith.NET の Metal 向け実装では、{transition} に相当する GPU 操作はありません。代わりにコマンドを描画・計算エンコーダーにまとめ、エンコーダー終了時に可視性バリアを挿入します。連続するコンピュートディスパッチなど、同じエンコーダー内の依存には明示的な {barrier} 呼び出しを使います。'
+concepts.synchronization.backends.details: '{link}では、グラフィックスのレンダーパスを開始すると計算エンコーダーが終了し、計算結果を描画処理から読み取れるようになります。連続する二つのコンピュートディスパッチは同じエンコーダー内にとどまるため、間にテクスチャ遷移を記録しても、依存を指定するバリアが必要です。'
concepts.synchronization.backends.details.link: 'コンピュートサンプル'
-concepts.synchronization.backends.title: 'バックエンドごとの動作'
+concepts.synchronization.backends.title: 'グラフィックス API ごとの同期'
concepts.synchronization.barriers.context: '関係するアクセスを含み、キューが対応しているステージを選びます。{barrierStagesAll} は対応するすべてのステージを含みます。依存関係が一部のステージだけに関わる場合は、その範囲に限定できます。'
concepts.synchronization.barriers.description: '同じコマンドバッファーに記録した二つのコンピュートディスパッチで、最初がシミュレーションデータを書き、次がそれを読む場合を考えます。その間にバリアを置くと、後のディスパッチが完了済みの書き込み結果を読み取れます。ストレージバッファーでは、テクスチャレイアウトを遷移させずにアクセスを順序付けられます。'
concepts.synchronization.barriers.details: '最初の引数はデータを生成したステージ、二つ目はそれを使用するステージを指定します。この二つで、ディスパッチ間に必要な実行順序とメモリの可視性を表します。'
-concepts.synchronization.barriers.guidance: '{link}では、シミュレーションの各段階の間にこの形のバリアを置きます。どのバリアも、データを生成するディスパッチの後、使用するディスパッチの前に記録します。'
+concepts.synchronization.barriers.guidance: '{link}では、シミュレーションの各段階の間にこの形のバリアを置きます。'
concepts.synchronization.barriers.guidance.link: 'FluidTank シミュレーション'
concepts.synchronization.barriers.title: 'パイプラインバリア'
concepts.synchronization.dependencies.description: '各リソースで、同じデータに触れるアクセスを確認します。一方でも書き込みを行う場合は、必要な順序を保ちます。二つの読み取りは競合しませんが、テクスチャレイアウトや提示の要件は満たす必要があります。CPU からの更新やリソースの解放も、対象領域を GPU が使い終わるまで待ちます。'
concepts.synchronization.dependencies.details: '操作の実行場所に応じて、使う仕組みを選びます。'
-concepts.synchronization.dependencies.guidance: '一つの処理に複数の同期手段が必要な場合もあります。例えば、別のキューで生成したテクスチャには、送信間の依存関係と、次の用途に適したレイアウトの両方が必要です。どちらも、それ自体は CPU の待機を必要としません。CPU がデータにアクセスしたり解放したりする場合に、CPU 側で待機します。'
+concepts.synchronization.dependencies.guidance: '一方のキューが書き込んだテクスチャを別のキューで使う場合は、送信間の依存関係を設定し、必要なレイアウト遷移を記録します。これらの操作で CPU は待機しません。CPU がデータにアクセスしたりリソースを解放したりする前には、処理の完了を待ってください。'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: '該当する完了値に対して {wait} を呼び出します。'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'CPU のアクセスやリソース解放に GPU の完了が必要な場合'
concepts.synchronization.dependencies.table.crossQueue.mechanism: '生成側の {timelineValue} を使用側の {submit} に渡します。'
concepts.synchronization.dependencies.table.crossQueue.situation: '別のキューで生成したデータを使用する場合'
-concepts.synchronization.dependencies.table.headings.mechanism: 'メカニズム'
+concepts.synchronization.dependencies.table.headings.mechanism: '同期手段'
concepts.synchronization.dependencies.table.headings.situation: '状況'
concepts.synchronization.dependencies.table.layoutChange.mechanism: '以前のレイアウトと次のレイアウトを指定した {commandBufferTransition}。'
concepts.synchronization.dependencies.table.layoutChange.situation: 'テクスチャサブリソースの使用方法の変更'
@@ -228,11 +226,11 @@ concepts.synchronization.dependencies.title: 'アクセス間の依存'
concepts.synchronization.description: '同期は、共有データへのアクセス順序を定め、後の操作が必要な結果を読み取れるようにします。書き込みから読み取りへの依存では、書き込む側を生成側、読む側を使用側と呼びます。バリアとテクスチャ遷移は GPU のアクセスを調整し、タイムラインは送信間の依存を設定したり、CPU で GPU の完了を待ったりするために使います。'
concepts.synchronization.layouts.context: '以前の内容を破棄できる場合は、遷移前のレイアウトに {undefined} を指定できます。例えば、新しい画像や全体をクリアするアタッチメントが該当します。ロード、サンプリング、蓄積のために内容を保持する場合は、直前のアクセスのレイアウトを使います。'
concepts.synchronization.layouts.description: '用途フラグは、テクスチャの許可された用途を宣言します。{textureLayout} は、コマンド列のある時点で、mip レベルと配列レイヤーで特定したサブリソースにどうアクセスするかを表します。アクセス方法が変わるときに遷移を記録します。例えばコンピュートサンプルでは、{storage} レイアウトで出力テクスチャへ書き込んだ後、グラフィックスパスでサンプリングする準備をします。'
-concepts.synchronization.layouts.details: 'ここでは {outputTexture} を {sampledStorage} 用途で作成し、対象サブリソースは {storage} です。{default} は mip レベル 0 と配列レイヤー 0 を選びます。他のレベルとレイヤーには影響しません。'
+concepts.synchronization.layouts.details: 'ここでは {outputTexture} を {sampledStorage} 用途で作成し、対象サブリソースのレイアウトは {storage} です。{default} は mip レベル 0 と配列レイヤー 0 を選びます。他のレベルとレイヤーには影響しません。'
concepts.synchronization.layouts.guidance: '{transition} には、サブリソースを前回使用したときのレイアウトを渡します。アプリケーションはコマンドを記録し、テクスチャを描画ステージ間で渡す際に、この状態を追跡します。'
concepts.synchronization.layouts.title: 'テクスチャレイアウト'
concepts.synchronization.readback.description: '{isCompleted} は GPU の完了を報告します。記録したリードバックには、その後にもう一つの処理があります。内部の読み戻し領域からアプリケーションの宛先メモリへ結果をコピーする処理です。'
-concepts.synchronization.readback.details: '{commandBufferDownload} は、この内部領域への GPU コピーを記録します。送信完了後、ライブラリはコマンドバッファーの回収時に CPU コピーを行います。リードバックの送信値に対して {wait} を呼ぶと、GPU を待機した後、そのキューの完了済みバッファーを処理し、両方のコピーが完了します。戻るまで宛先を確保し、管理対象メモリは固定したままにしてください。'
+concepts.synchronization.readback.details: '{commandBufferDownload} は、この内部領域への GPU コピーを記録します。送信完了後、ライブラリはコマンドバッファーの回収時に CPU コピーを行います。リードバックの送信値に対して {wait} を呼ぶと、GPU の処理が完了するのを待った後、そのキューの完了済みバッファーを処理し、両方のコピーが完了します。戻るまで宛先を確保し、管理対象メモリは固定したままにしてください。'
concepts.synchronization.readback.guidance: '{isCompleted} の確認だけでは、最後の CPU コピーは行われません。別のキューで待機しても、リードバックを管理するキューのバッファーは回収されません。アップロードとリードバックが直接アクセスや一時領域を使う条件は、{link}で説明します。'
concepts.synchronization.readback.guidance.link: 'リソース管理'
concepts.synchronization.readback.title: 'リードバックの完了'
@@ -256,7 +254,7 @@ home.entries.reference.category: 'リファレンス'
home.entries.reference.description: 'API の型、メンバー、宣言を調べる'
home.entries.reference.title: 'API リファレンス'
home.entries.samples.action: 'サンプルを参照'
-home.entries.samples.category: 'サンプル'
+home.entries.samples.category: 'コード例'
home.entries.samples.description: '描画と計算の手法を実行できるサンプルで学ぶ'
home.entries.samples.title: 'サンプル'
home.entries.title: 'ドキュメント'
@@ -265,9 +263,9 @@ home.entries.tutorial.category: 'チュートリアル'
home.entries.tutorial.description: '空のプロジェクトから、最初の三角形を描くまで'
home.entries.tutorial.title: '最初の三角形'
home.introduction.accent: 'クロスプラットフォームのグラフィックス'
-home.introduction.description: 'Zenith.NET は、共通の API で DirectX、Metal、Vulkan の描画と計算を扱うライブラリです'
+home.introduction.description: 'Zenith.NET は DirectX 12、Metal 4、Vulkan 1.4 に共通の描画・計算 API を提供します'
home.introduction.title: '.NET でつくる{lineBreak}{accent}'
-home.meta.description: 'DirectX、Metal、Vulkan に共通の API を使い、.NET でクロスプラットフォームの描画・計算アプリケーションを開発'
+home.meta.description: 'DirectX 12、Metal 4、Vulkan 1.4 に共通の API で描画と計算を扱う .NET 向けクロスプラットフォーム RHI'
home.scene.description: '回転する図形を操作できます。ドラッグまたは矢印キーで視点を調整してください。'
home.scene.label: 'ジオメトリ表示'
home.scene.surface: 'サーフェス'
@@ -290,71 +288,65 @@ learning.title: '学習'
reference.description: 'リソース、コマンド、プラットフォーム統合のリファレンス'
reference.entries.commands.description: '描画、計算、転送のコマンド'
reference.entries.commands.label: 'コマンドを記録'
-reference.entries.context.description: '選択したバックエンドの GPU リソース作成'
+reference.entries.context.description: 'グラフィックスコンテキストによる GPU リソースの作成'
reference.entries.context.label: 'ここから開始'
reference.meta.description: 'Zenith.NET の名前空間、型、メンバー'
reference.navigation.core: 'コア API リファレンス'
reference.title: 'API リファレンス'
-samples.computeShader.description: 'サンプルは {assetsTexturesShokoPng} を読み込み、コンピュートディスパッチでグレースケールに変換して、出力テクスチャを表示します。変換は一度だけ行い、以降のフレームでは同じ結果を表示します。レンダラーでは、サンプリング用と書き込み用テクスチャのバインド、画像全体を覆うためのグループ数の切り上げ、シェーダー内の境界検査を確認できます。'
+samples.computeShader.description: 'コンピュートシェーダーがカラー画像をグレースケールに変換し、GPU による画像処理を示します。'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: 'コンピュートシェーダー'
-samples.cube.description: '立方体では、インデックス付き描画、定数バッファー内のモデル・ビュー・投影行列、深度テストを加えます。{d32FloatS8UInt} の深度ステンシルテクスチャはリサイズ時に再作成します。'
+samples.cube.description: '回転する立方体で、インデックス付きジオメトリ、3D 変換、深度テストを扱います。'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: '回転する立方体'
-samples.description: '各サンプルは C# のレンダラーと Slang シェーダーを組み合わせ、一つの手法を扱います。アプリケーションの準備から描画までの手順は、{link}で説明します。'
-samples.description.link: '最初の三角形'
+samples.description: '三角形一つの表示からインタラクティブなアプリケーションや診断ツールまで、描画と計算の例を紹介します。'
samples.execution.description: '{link} プロジェクトを実行し、コンソールメニューからサンプルを選びます。'
samples.execution.description.link: 'ZenithTutorials'
samples.execution.title: 'サンプルの実行'
-samples.host.description: '{appCs} はコンテキスト、ウィンドウ、スワップチェーンを初期化します。各フレームではコマンドバッファーを取得し、選択したレンダラーを呼び、送信と提示を行います。{iRendererCs} は更新、描画、リサイズ、解放の操作を定義します。'
-samples.host.details: 'コンピュートとレイトレーシングのレンダラーは、オフスクリーンテクスチャを生成します。{texturePresenterCs} と {presentTextureSlang} がその内容を現在の drawable に描画し、共通ホストがコマンドを送信してフレームを提示します。'
-samples.host.title: 'ホストと提示'
-samples.indirectDrawing.description: '間接描画では、インデックス付き描画の引数バッファーとインスタンスごとの構造化データを使い、複数の立方体を描きます。CPU が引数を設定し、変換を更新します。'
+samples.indirectDrawing.description: '色の異なる立方体を格子状に並べて回転させ、描画引数バッファーを使った間接描画を示します。'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: '間接描画'
-samples.meshShading.description: 'タスクシェーダーが球のインスタンスをカリングし、残ったインデックスを、ジオメトリを生成するメッシュシェーダーへ渡します。パイプライン作成前に {contextCapabilitiesMeshShadingSupported} を確認します。'
+samples.meshShading.description: 'このサンプルではタスクシェーダーとメッシュシェーダーを使い、カメラの視野外にある球を除外しながら、色付きの球を格子状に描画します。メッシュシェーディングへの対応が必要です。'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: 'メッシュシェーディング'
-samples.rayTracing.description: '床と手続き的な球の下位・上位アクセラレーション構造を構築し、コンピュートシェーダー内でインラインレイクエリを実行します。初期化前に {contextCapabilitiesRayTracingSupported} を確認します。'
+samples.rayTracing.description: 'このサンプルではレイクエリを使い、市松模様の床の上に、周囲を反射する球とその影を描きます。レイトレーシングへの対応が必要です。'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: 'レイトレーシング'
samples.title: 'サンプル'
-samples.triangle.description: '頂点バッファーと対応する入力レイアウトを関連付け、グラフィックスパイプラインで三つの頂点から三角形を描きます。'
+samples.triangle.description: '頂点色が滑らかにつながる三角形を通して、グラフィックスパイプラインの基本を紹介します。'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: '完全なチュートリアル'
samples.triangle.title: 'Hello Triangle'
-samples.workloads.description: 'メインリポジトリの {link} にある応用例は、ライブラリのソースを直接参照しています。'
+samples.workloads.description: 'Zenith.NET リポジトリの {link}には、次のアプリケーションとツールがあります。'
samples.workloads.description.link: 'Experiments ディレクトリ'
-samples.workloads.details: 'ウィンドウ付きの実験は同じ Windows、macOS、Linux/X11 の提示経路を使います。Avalonia、WinForms、WPF、WinUI/Uno、MAUI のコントロールは、フレーム処理と実装ソースを含めて{link}で紹介します。'
-samples.workloads.details.link: 'プラットフォーム統合'
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: 'CornellBox'
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'パストレーシング、ノイズ除去、トーンマッピング、アップスケーリング、ImGui による操作を扱います。レイトレーシング対応が必要です。'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '光の当たり方や反射を観察できるインタラクティブな室内シーンです。レイトレーシングへの対応が必要です。'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: 'FluidTank'
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '計算による流体シミュレーション、段階間の依存、複数パスの表面描画を扱います。'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '水面表示と粒子表示を備えた、水槽内の水のシミュレーションです。'
samples.workloads.table.headings.example: '例'
-samples.workloads.table.headings.whatItDemonstratesAndRequires: '手法と要件'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: '概要'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: 'InkCanvas'
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'ネイティブウィンドウで Skia の描画と入力処理を行います。対象プラットフォームのバックエンドと Skia ネイティブライブラリが必要です。'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'フリーハンドで線を描き、消せるキャンバスです。'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: 'PlatformDetection'
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '各バックエンドのコンテキスト作成を試み、デバイスの機能を報告します。作成に失敗した場合は非対応と表示しますが、原因にはデバイス、ドライバー、実行時依存の不足が考えられます。'
-samples.workloads.title: 'より大きなアプリケーション'
-tutorial.context.description: '{graphicsContext} はバックエンドを介してアプリケーションを GPU に接続し、描画リソースを作成するためのメソッドを提供します。'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'グラフィックス API の利用可否とデバイスの機能を表示するコンソールツールです。'
+samples.workloads.title: 'アプリケーションとツール'
+tutorial.context.description: '{graphicsContext} は選択したグラフィックス API を通じてアプリケーションを GPU に接続し、描画リソースを作成するためのメソッドを提供します。'
tutorial.context.details: 'コンテキストの初期化を{emphasis}に追加します。'
tutorial.context.details.emphasis: 'using ディレクティブの後、{iWindowWindow} の前'
-tutorial.context.guidance: '各分岐でプラットフォームに応じたバックエンドを選び、検証を要求します。{validationMessage} のメッセージはコンソールに出力します。'
+tutorial.context.guidance: '各分岐で選んだグラフィックス API の検証を要求します。実装から {validationMessage} の診断メッセージが届いた場合、ハンドラーがコンソールに出力します。'
tutorial.context.imports: '{programCs} の先頭に、次の using ディレクティブを追加します。'
tutorial.context.title: 'グラフィックスコンテキスト'
tutorial.description: 'このチュートリアルでは、空の .NET コンソールプロジェクトから始め、ウィンドウを開いて色付きの三角形を描くアプリケーションを作成します。'
tutorial.details: 'このチュートリアルでは、空のウィンドウ、単色の背景、色付きの三角形の三段階で結果を確認します。各段階でアプリケーションを実行し、表示を確かめてから次へ進んでください。'
tutorial.draw.context: '{draw} の引数は次のとおりです。'
tutorial.draw.description: '{windowRender} コールバックの {addTheTriangleDrawCommandsHereLater} を、次のコマンドで置き換えます。位置は {beginRenderPass} と {endRenderPass} の間です。'
-tutorial.draw.details: '{setPipeline} はシェーダーと描画状態を選択します。頂点のバインドはパイプラインの入力レイアウトに従って解釈されるため、その前に呼びます。'
+tutorial.draw.details: '{setPipeline} はシェーダーと描画状態を選択します。頂点バッファーをバインドする前にパイプラインを選びます。入力レイアウトが頂点データの読み方を決めるためです。'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} は、転送済みの頂点データをバイトオフセット 0 から入力スロット 0 にバインドします。これは {inputLayouts} の唯一の要素に対応します。'
-tutorial.draw.notes: 'これらの呼び出しは描画コマンドを記録します。既存の {submitWait} がコマンドを送信して GPU の完了を待ち、その後 {present} が完成した画像の表示を要求します。三角形の外側にも決まった背景色を表示するため、パスの先頭のクリア処理は残します。'
+tutorial.draw.notes: '三角形の外側にも決まった背景色を表示するため、パスの先頭のクリア処理は残します。'
tutorial.draw.table.firstInstance.meaning: 'インスタンスの番号付けをゼロから開始します。'
tutorial.draw.table.firstVertex.meaning: 'バッファー内の最初の頂点から開始します。'
tutorial.draw.table.headings.argument: '引数'
@@ -370,25 +362,25 @@ tutorial.execution.title: 'アプリケーションの実行'
tutorial.frame.commands.context: '{endRenderPass} の後、二回目の遷移で出力テクスチャを提示可能な状態にします。{submit} は記録を終えてコマンドを送信し、{wait} はその完了まで待機します。続く {present} が描画済み画像の表示を要求します。'
tutorial.frame.commands.description: 'レンダーパスは、同じアタッチメントに書き込む描画操作をまとめます。このパスではスワップチェーンの drawable が色の出力先です。{colorAttachmentClear} は、アタッチメントを RGBA 色で初期化し、パス終了時に内容を保持するよう指定します。{beginRenderPass} は、この設定でパスを開始するコマンドを記録します。'
tutorial.frame.commands.details: 'コレクションにはカラーアタッチメントを一つ入れます。{null} は深度ステンシルアタッチメントを使わない指定です。'
-tutorial.frame.commands.guidance: '{beginRenderPass} は、アタッチメント全体を覆うビューポートとシザーを設定します。ビューポートは描画座標をピクセル位置に変換し、シザーは書き込める範囲を制限します。'
+tutorial.frame.commands.guidance: '{beginRenderPass} は、アタッチメント全体を覆うビューポートとシザーを設定します。ビューポートは描画座標をピクセル位置に変換し、シザーは描画対象のピクセル範囲を制限します。'
tutorial.frame.commands.title: 'クリア、送信、提示'
-tutorial.frame.description: 'まず、ウィンドウを単色の背景で埋めます。この操作をクリアと呼びます。背景が表示されれば、サーフェス、コマンド送信、提示の流れが動いています。ここに三角形の頂点とシェーダーを加えていきます。'
-tutorial.frame.details: 'Silk.NET は描画のタイミングでコールバックを呼びます。この例では経過時間の引数を使わないため、パラメーター名を {value} にしています。コールバックを{emphasis}に登録します。'
+tutorial.frame.description: 'まずウィンドウを単色で塗りつぶします。これをクリアと呼びます。色が表示されれば、コマンドの送信と提示が動作しています。次に三角形の頂点とシェーダーを追加します。'
+tutorial.frame.details: 'Silk.NET は描画のタイミングでコールバックを呼びます。コールバックを{emphasis}に登録します。'
tutorial.frame.details.emphasis: '{windowRun} の前'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} は記録可能なコマンドバッファーを返します。記録は GPU の処理を定義する段階であり、実行は送信後に始まります。'
+tutorial.frame.target.description: 'コマンドキューは、GPU で実行するための記録済み処理を受け付けます。{graphicsQueueCommandBuffer} は、すでに記録が始まっているコマンドバッファーを返します。記録したコマンドが GPU の処理を定義し、実行は送信後に始まります。'
tutorial.frame.target.details: 'テクスチャレイアウトは、操作がテクスチャにどうアクセスするかを表します。最初の {transition} で、出力テクスチャをカラーアタッチメントとして使える状態にします。ここでの {default} は mip レベル 0 と配列レイヤー 0、つまり出力テクスチャの基本画像を選びます。このパスでは画像全体をクリアするため、{undefined} を指定して以前の内容を破棄できます。'
tutorial.frame.target.guidance: '提示すると別の画像に切り替わることがあるため、毎フレーム、現在の drawable を取得します。'
tutorial.frame.target.title: 'drawable の準備'
tutorial.frame.title: '最初のフレーム'
tutorial.geometry.data.description: '頂点配列を{emphasis}に追加します。以後のリソース初期化も、説明する順序でこのコールバックの前に置きます。'
tutorial.geometry.data.description.emphasis: '{windowRender} の前'
-tutorial.geometry.data.details: '各要素は {vertex} を作り、内側の二つの {new} が {vector3} の位置と {vector4} の色を渡します。位置は上、右下、左下の頂点です。頂点シェーダーで第四成分 {w} を加えます。w が 1 なので x と y は正規化デバイス座標でもあり、-1 と +1 が画像の端、0 が中央を表します。この意味はピクセル寸法に依存しません。'
+tutorial.geometry.data.details: '三つの位置は、上、右下、左下の頂点を表します。この例では、画像全体の x と y を -1 から +1 の範囲で表し、0 が中央、x の正方向が右、y の正方向が上になります。'
tutorial.geometry.data.guidance: '各色は赤、緑、青、アルファの成分を持ち、アルファは 1 です。三つの頂点はすべて z = 0 で、同じ平面上にあります。'
tutorial.geometry.data.title: '頂点の位置と色'
tutorial.geometry.description: '三角形の各頂点には位置と色があります。GPU は三つの位置から形を決め、頂点色を補間して内部の色を求めます。'
tutorial.geometry.format.description: '頂点の宣言を{emphasis}に追加します。'
tutorial.geometry.format.description.emphasis: '{programCs} の末尾、解放処理の後'
-tutorial.geometry.format.details: '{file} は型の使用範囲を {programCs} に限定し、{layoutKindSequential} はフィールドの宣言順を保ちます。{position} は三つの 32 ビット浮動小数点数を含み、バイトオフセット 0 から始まります。{color} は四つを含み、バイトオフセット 12 から始まります。したがって、頂点一つの大きさは 28 バイトです。後で入力レイアウトにこの配置を指定し、GPU が各フィールドを正しく読めるようにします。'
+tutorial.geometry.format.details: '{layoutKindSequential} はフィールドの宣言順を保ちます。{position} は三つの 32 ビット浮動小数点数を含み、バイトオフセット 0 から始まります。{color} は四つを含み、バイトオフセット 12 から始まります。したがって、頂点一つの大きさは 28 バイトです。後で入力レイアウトにこの配置を指定し、GPU が各フィールドを正しく読めるようにします。'
tutorial.geometry.format.imports: 'ベクトル型と構造体のレイアウト属性を使うため、{programCs} の先頭に次の using ディレクティブを追加します。'
tutorial.geometry.format.title: '頂点の表現'
tutorial.geometry.title: '頂点データ'
@@ -397,9 +389,8 @@ tutorial.geometry.upload.description: '描画時に GPU が読み取れるよう
tutorial.geometry.upload.details: 'サイズは {sizeofVertexVerticesLength}、つまり 28 バイトの頂点三つで 84 バイトです。{bufferUsagesVertex} は頂点入力用途、{cpuWriteOnly} は CPU による直接初期化を許可します。記述のストライドは要素サイズを表します。各属性の読み方は、後で作る入力レイアウトが定めます。'
tutorial.geometry.upload.guidance: '確保しただけではデータは入りません。{upload} が、データ記述に渡した元ポインターとバイト数を使い、配列をバッファーのオフセット 0 にコピーします。'
tutorial.geometry.upload.imports: 'Zenith.NET のバッファー型を {systemBuffer} と区別するため、{programCs} の using ディレクティブに {bufferAlias} を追加します。'
-tutorial.geometry.upload.notes: '{programCs} 末尾の解放処理で、{swapChainDispose} の直前に {vertexBufferDispose} を加えます。大きな静的ジオメトリ向けの GPU 専用メモリと転送は{link}で説明します。'
-tutorial.geometry.upload.notes.link: 'リソース管理'
-tutorial.geometry.upload.title: 'バッファーの確保と転送'
+tutorial.geometry.upload.notes: '{programCs} 末尾の解放処理で、{swapChainDispose} の直前に {vertexBufferDispose} を加えます。'
+tutorial.geometry.upload.title: 'バッファーの確保とアップロード'
tutorial.input.description: 'GPU は位置や色などの頂点属性がどこにあるかを知る必要があります。入力レイアウトで各属性のフォーマットとバイトオフセットを指定し、ストライドで次の頂点までのバイト数を示します。シェーダー作成後に次のコードを加えます。'
tutorial.input.details: '{inputLayoutAdd} は属性を順番に並べ、各属性のサイズをストライドに加算します。オフセットは C# の構造体を調べて得るのではなく、ここで指定したフォーマットから計算されます。この二つのフィールドでは、次の配置になります。'
tutorial.input.guidance: '{semanticIndex} の既定値は 0 で、シェーダーの {pOSITION0} と {cOLOR0} に対応します。位置と色は一つの頂点バッファーに格納するため、パイプラインにはスロット 0 の入力レイアウトを一つ指定します。C# のフィールド順やパディングを変えた場合は、入力レイアウトも合わせて変更してください。'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: '次の入力レコード'
tutorial.input.table.vertexColor.format: '{float4} (16 バイト)'
tutorial.input.table.vertexPosition.format: '{float3} (12 バイト)'
tutorial.input.title: '頂点入力レイアウト'
-tutorial.lifecycle.description: '各フレームは次の順で進みます。'
-tutorial.lifecycle.details: 'ウィンドウを閉じると {run} が戻り、解放処理へ進みます。各フレームで送信した処理の完了を待っているため、その処理で使用したリソースは解放できます。{windowRun} の後に置く解放処理の全体は次のとおりです。'
+tutorial.lifecycle.description: '各フレームでは現在の drawable を取得し、描画用に遷移させ、クリアして三角形を描きます。続いて提示用に遷移させ、コマンドを送信し、完了を待ってから画像を提示します。'
+tutorial.lifecycle.details: 'ウィンドウを閉じると {run} が戻り、解放処理へ進みます。描画コールバックは各フレームを送信した後にその完了を待っているため、その処理で使用したリソースは解放できます。{windowRun} の後に置く解放処理の全体は次のとおりです。'
tutorial.lifecycle.guidance: 'スワップチェーンはネイティブウィンドウを破棄する前に、コンテキストはそのリソースを解放した後に解放します。送信済みコマンドバッファーはキューが回収し、drawable はスワップチェーンが管理するため、どちらにも個別の {dispose} 呼び出しは不要です。'
-tutorial.lifecycle.title: 'フレームの流れと終了処理'
tutorial.pipeline.behavior: '入力レイアウトの後にパイプラインを作成します。'
tutorial.pipeline.context: '{cullNone} は面のカリングを無効にします。頂点が画面上で時計回りに並んでいても、反時計回りに並んでいても、三角形を描画します。'
tutorial.pipeline.description: '{graphicsPipeline} は、頂点レイアウト、二つのシェーダー、プリミティブの組み立てとアタッチメントへの出力設定をまとめます。'
-tutorial.pipeline.details: '頂点とフラグメントの処理はシェーダーが担当します。パイプラインの残りの設定では、プリミティブの組み立て、面のカリング、深度テスト、ブレンドを指定します。'
tutorial.pipeline.guidance: 'パイプラインのカラーフォーマットはパスのアタッチメントに合わせ、{swapChainDescFormat} から取得します。{count1} は一ピクセル一サンプルです。'
tutorial.pipeline.item: '{triangleList} は連続する三つの頂点を一組として、三角形を組み立てます。'
tutorial.pipeline.notes: '{depthNone} は深度テストと深度書き込みを無効にします。深度アタッチメントを使わないパスと対応します。'
@@ -428,28 +417,25 @@ tutorial.pipeline.reference: '{opaque} はブレンドを無効にします。
tutorial.pipeline.title: 'グラフィックスパイプライン'
tutorial.pipeline.usage: 'シェーダーオブジェクトはパイプライン作成後に解放できます。パイプラインは描画中保持し、終了処理で {vertexBufferDispose} の前に {pipelineDispose} を加えます。'
tutorial.presentation.title: 'グラフィックスコンテキストと提示'
-tutorial.project.context: 'プロジェクトのビルド設定で {emphasis}({allowUnsafeBlocks})を有効にします。ウィンドウ補助コードのネイティブ呼び出しと頂点の転送に unsafe コードが必要です。'
+tutorial.project.context: 'プロジェクトのビルド設定で {emphasis}({allowUnsafeBlocks})を有効にします。ウィンドウ補助クラスのネイティブ呼び出しと頂点の転送に unsafe コードが必要です。'
tutorial.project.context.emphasis: 'アンセーフコードの許可'
tutorial.project.description: '.NET 10 を対象とする、{firstTriangle} という名前の C# コンソールプロジェクトを作成します。'
tutorial.project.details: 'プロジェクトに次の NuGet パッケージを追加します。'
-tutorial.project.guidance: '{zenithNET} が共通の描画 API を、三つのバックエンドパッケージが各実装を提供します。{zenithNETCompiler} は後で作る Slang シェーダーを対象バックエンド向けにコンパイルします。Silk.NET はウィンドウの作成とイベント処理を担当します。'
+tutorial.project.guidance: '{zenithNET} は描画と計算の共通 API を提供し、三つのグラフィックス API 向けパッケージがその API を実装します。{zenithNETCompiler} は選択した API 向けに Slang シェーダーをコンパイルします。'
tutorial.project.title: 'プロジェクトの準備'
-tutorial.requirements.context: '{link}とその{detail}が、このチュートリアルの参照実装です。'
-tutorial.requirements.context.detail: '共有ホスト'
-tutorial.requirements.context.link: 'Hello Triangle サンプル'
-tutorial.requirements.description: '{emphasis} と C# の基礎知識が必要です。アプリケーションの対象フレームワークは {net10} です。GPU とドライバーは、プラットフォームごとに選ぶ次のバックエンドに対応している必要があります。'
+tutorial.requirements.description: '{emphasis} と C# の基礎知識が必要です。GPU とドライバーは、使用するプラットフォームに応じて次のグラフィックス機能に対応している必要があります。'
tutorial.requirements.description.emphasis: '.NET 10 SDK'
-tutorial.requirements.guidance: 'Zenith.NET はアプリケーションから渡されたネイティブサーフェスへ描画します。Silk.NET.Windowing がウィンドウとイベントを管理します。macOS の提示には {cAMetalLayerCs} で表される Metal レイヤーを使い、補助コードがウィンドウへ取り付けます。'
-tutorial.requirements.table.headings.graphicsBackend: 'グラフィックスバックエンド'
+tutorial.requirements.guidance: 'Zenith.NET はアプリケーションから渡されたネイティブサーフェスへ描画します。Silk.NET.Windowing がウィンドウを作成し、イベントを処理します。'
+tutorial.requirements.table.headings.graphicsBackend: '必要なグラフィックス機能'
tutorial.requirements.table.headings.platform: 'プラットフォーム'
-tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4'
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 と VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux(X11 または XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: 'Metal 4'
tutorial.requirements.table.macOS.platform: 'macOS'
-tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12'
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 と Shader Model 6.6'
tutorial.requirements.table.windows.platform: 'Windows'
tutorial.requirements.title: '前提条件'
-tutorial.resize.context: 'アプリケーションをもう一度ビルドして実行します。リサイズしても背景がウィンドウ全体を覆うことを確認してください。新しいレンダーパスでは、変更後のアタッチメントの寸法からビューポートとシザーが設定されます。描画コールバックはそのまま残し、後でこのパスに三角形の描画を加えます。'
+tutorial.resize.context: 'アプリケーションをもう一度ビルドして実行します。リサイズしても背景がウィンドウ全体を覆うことを確認してください。描画コールバックはそのまま残し、後でこのパスに三角形の描画を加えます。'
tutorial.resize.description: 'フレームバッファーの寸法が変わったら、スワップチェーンも合わせて変更します。描画コールバックの後、{windowRun} の前に {framebufferResize} のコールバックを登録します。'
tutorial.resize.details: 'ウィンドウの論理寸法ではなく、ピクセル単位の{link}を受け取ります。最小化によって幅か高さがゼロになった場合、リサイズコールバックはスワップチェーンを変更しません。描画コールバックも、どちらかの寸法がゼロの間はそのまま戻ります。有効な寸法に戻るまで描画を中断するためです。'
tutorial.resize.details.link: 'フレームバッファーサイズの変化'
@@ -461,51 +447,33 @@ tutorial.shaders.compilation.description: '{triangleSlang} のファイルプロ
tutorial.shaders.compilation.description.detail: '新しい場合はコピーする'
tutorial.shaders.compilation.description.emphasis: '出力ディレクトリにコピー'
tutorial.shaders.compilation.details: '{programCs} に戻り、頂点のアップロード後、描画コールバック前にシェーダーの初期化を追加します。'
-tutorial.shaders.compilation.guidance: '{zenithCompiler} は {contextGraphicsApi} のバックエンド向けにソースをコンパイルします。{createShader} は、コンパイル済みの記述からシェーダーオブジェクトを作成します。エントリーポイント名 {vSMain} と {fSMain} は、Slang ファイルに定義した二つの関数を選択します。'
+tutorial.shaders.compilation.guidance: '{zenithCompiler} は {contextGraphicsApi} で選択したグラフィックス API 向けにソースをコンパイルします。{createShader} は、コンパイル済みの記述からシェーダーオブジェクトを作成します。エントリーポイント名 {vSMain} と {fSMain} は、Slang ファイルに定義した二つの関数を選択します。'
tutorial.shaders.compilation.title: 'シェーダーのコンパイル'
tutorial.shaders.context: '{fSInput} は二つのシェーダーステージをつなぎます。頂点シェーダーはクリップ空間の位置を {sVPOSITION} に書き込み、GPU はその位置から三角形の見える範囲を判断します。{cOLOR0} は頂点色を渡すフィールドです。色は三角形の内部で補間されてから、フラグメントシェーダーに届きます。両ステージで色の型とセマンティクスを一致させる必要があります。'
-tutorial.shaders.description: 'シェーダーは GPU 上で実行するプログラムです。頂点シェーダーは各頂点の位置を決め、フラグメントシェーダーは画像の覆われた位置の色を決めます。両ステージを一つの Slang ファイルに書き、それぞれにエントリーポイントを定義します。エントリーポイントは、そのステージの実行が始まる関数です。'
-tutorial.shaders.details: '{triangleSlang} を作成し、次の入出力構造体を書きます。'
+tutorial.shaders.description: 'シェーダーは GPU 上で実行するプログラムです。頂点シェーダーは各頂点の位置を決め、フラグメントシェーダーは図形が覆う画像上の位置の色を決めます。両ステージを一つの Slang ファイルに書き、それぞれにエントリーポイントを定義します。エントリーポイントは、そのステージの実行が始まる関数です。'
+tutorial.shaders.details: 'プロジェクトのルートに {triangleSlang} を作成し、次の入出力構造体を書きます。'
tutorial.shaders.fragment.description: '同じファイルにフラグメントのエントリーポイントを追加します。'
tutorial.shaders.fragment.details: 'ラスタライズは三角形が画像を覆う範囲を調べ、その位置にフラグメントを生成します。各フラグメントの色は、三つの頂点色を補間して求めます。{fSMain} がその色を返し、{sVTARGET} が最初のカラーアタッチメントへの出力を指定します。'
tutorial.shaders.fragment.title: 'フラグメントシェーダー'
tutorial.shaders.guidance: '{vSInput} は頂点シェーダーの入力です。{pOSITION0} と {cOLOR0} はセマンティクスによって属性を対応付けます。C# のフィールド名だけでは、この対応は決まりません。'
tutorial.shaders.title: 'シェーダーステージ'
tutorial.shaders.vertex.description: '{triangleSlang} に頂点のエントリーポイントを追加します。'
-tutorial.shaders.vertex.details: 'GPU は入力頂点ごとにこの関数を呼びます。同次座標 {w} を追加し、色をそのまま渡します。頂点処理後に位置を w で割りますが、ここでは 1 なので x、y、z は変わらず、正規化デバイス座標として直接解釈できます。'
+tutorial.shaders.vertex.details: 'GPU は入力頂点ごとにこの関数を実行します。位置に四つ目の成分 {w} を加え、色をそのまま渡します。頂点処理後、GPU は x、y、z を w で割って正規化デバイス座標を求めます。ここでは w が 1 なので、各値は変わりません。'
tutorial.shaders.vertex.title: '頂点シェーダー'
tutorial.surface.description: 'ネイティブの提示先を{emphasis}に指定します。'
tutorial.surface.description.emphasis: '{windowCenter} の後、{windowRun} の前'
tutorial.surface.details: 'フレームバッファーは、ウィンドウが表示するピクセル画像です。{surface} はネイティブの提示先と寸法を記述し、{framebufferSize} はピクセル単位のサイズを返します。表示倍率によっては、ウィンドウの論理サイズと異なります。'
-tutorial.surface.guidance: 'サーフェスにはバックエンドが必要とするネイティブハンドルを渡します。Windows は Win32 ウィンドウ、Linux は X11 のディスプレイとウィンドウ、macOS は取り付けた Metal レイヤーを使います。'
+tutorial.surface.guidance: 'サーフェスには選択したグラフィックス API で必要なネイティブハンドルを渡します。Windows は Win32 ウィンドウ、Linux は X11 のディスプレイとウィンドウ、macOS は取り付けた Metal レイヤーを使います。'
tutorial.surface.title: 'ネイティブサーフェス'
tutorial.swapChain.context: 'スワップチェーンはコンテキストとウィンドウの両方に依存します。{programCs} 末尾の {windowDispose} を次の解放順序に置き換えます。'
tutorial.swapChain.description: 'サーフェス記述の直後にスワップチェーンを作成します。'
tutorial.swapChain.details: '{swapChain} はウィンドウが提示する画像を管理します。{drawable} は現在の画像を、API の画像リソースである {texture} として返します。描画後に {present} が表示を要求し、次の drawable へ進みます。'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} は青、緑、赤、アルファの順に各 8 ビットを格納します。{uNorm} は整数 0~255 を 0~1 に対応付けます。シェーダー出力は論理的な RGBA のままで、フォーマットは保存表現を定めます。パイプラインは {swapChainDescFormat} でこのアタッチメントに合わせます。'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} は青、緑、赤、アルファの順に各 8 ビットを格納します。{uNorm} は整数 0~255 を 0~1 に対応付けます。シェーダー出力は論理的な RGBA のままで、フォーマットは保存表現を定めます。'
tutorial.swapChain.title: 'スワップチェーン'
tutorial.title: '最初の三角形'
-tutorial.troubleshooting.description: 'コンソールの診断と三段階の結果を使い、問題のある箇所を特定します。'
-tutorial.troubleshooting.details: '{link}と{detail}で頂点データ、入力レイアウト、描画操作を照合できます。サンプルはウィンドウと送信を共通ホストへ分離していますが、このチュートリアルの処理は {programCs} にまとめています。{context}ではインデックス付き描画、変換、深度テストへ進みます。'
-tutorial.troubleshooting.details.context: '回転する立方体'
-tutorial.troubleshooting.details.detail: 'Slang シェーダー'
-tutorial.troubleshooting.details.link: 'サンプルレンダラー'
-tutorial.troubleshooting.table.backend.check: '選択したバックエンドがデバイスおよびインストールされているグラフィックスドライバーでサポートされていることを確認してください。'
-tutorial.troubleshooting.table.backend.symptom: 'バックエンドの作成に失敗する'
-tutorial.troubleshooting.table.drawing.check: 'アップロードサイズ、入力レイアウト、パイプラインの選択、およびレンダーパス内の描画コマンドの配置を確認してください。'
-tutorial.troubleshooting.table.drawing.symptom: '背景は表示されるが三角形が表示されない'
-tutorial.troubleshooting.table.headings.check: '確認事項'
-tutorial.troubleshooting.table.headings.symptom: '症状'
-tutorial.troubleshooting.table.input.check: 'ストライドが 28 バイト、位置と色のオフセットがそれぞれ 0 と 12 バイトであることを確認します。'
-tutorial.troubleshooting.table.input.symptom: '頂点の位置や色が破損している'
-tutorial.troubleshooting.table.shaders.check: 'コピーされた {triangleSlang}、エントリーポイントのスペル、およびコンパイラーが報告した診断情報を確認してください。'
-tutorial.troubleshooting.table.shaders.symptom: '背景色は表示されるがシェーダーを読み込めない'
-tutorial.troubleshooting.table.window.check: '.NET プロジェクトがビルドされ、ウィンドウ単体のステップがデスクトップセッションで実行されることを確認してください。Linux では、X11 または XWayland が利用可能であることを確認してください。'
-tutorial.troubleshooting.table.window.symptom: 'ウィンドウが開かない'
-tutorial.troubleshooting.title: '問題の切り分け'
tutorial.window.description: '{cocoaHelperCs} をダウンロードしてプロジェクトに追加します。この補助クラスが macOS のウィンドウに Metal レイヤーを取り付けます。'
-tutorial.window.details: '自動生成された {programCs} の内容を、次のコードに置き換えます。トップレベルステートメントを使うため、明示的な {main} メソッドを書かずに、上から順に実行できます。続く各節でコードを追加する位置を示します。'
-tutorial.window.guidance: '{graphicsAPINone} で、グラフィックスコンテキストの作成を Zenith.NET に任せます。{initialize} はネイティブウィンドウを作り、ウィンドウシステムのハンドルを利用可能にします。{center} で画面中央に置き、{run} で閉じるまでイベントを処理します。その後、{dispose} でウィンドウを解放します。'
+tutorial.window.details: '{programCs} の内容を、次のコードに置き換えます。'
+tutorial.window.guidance: '{graphicsAPINone} で Silk.NET によるグラフィックスコンテキストの作成を無効にします。コンテキストは後で Zenith.NET で作成します。{initialize} はネイティブウィンドウを作り、ウィンドウシステムのハンドルを利用可能にします。{center} で画面中央に置き、{run} で閉じるまでイベントを処理します。その後、{dispose} でウィンドウを解放します。'
tutorial.window.notes: 'アプリケーションをビルドして実行し、ウィンドウを開く、移動する、リサイズする、閉じるという操作を確認します。描画コマンドはまだ送信していないため、表示内容は未定義です。次へ進む前にウィンドウを閉じてください。'
tutorial.window.title: 'ウィンドウの作成'
ui.action.copy: 'コピー'
@@ -525,7 +493,7 @@ ui.api.noNamespaceTypes: 'この名前空間には型がありません。'
ui.api.noTypes: '一致する型はありません。'
ui.api.types: '型'
ui.content.reference: 'リファレンス'
-ui.content.source: 'ソースコード'
+ui.content.examples: 'コード例'
ui.content.tutorial: 'チュートリアル'
ui.contents.close: '目次を閉じる'
ui.contents.open: '目次を開く'
@@ -562,7 +530,6 @@ ui.reference.exceptions: '例外'
ui.reference.extensionMethods: '拡張メソッド'
ui.reference.fields: 'フィールド'
ui.reference.implementations: '明示的なインターフェイスの実装'
-ui.reference.implements: '実装'
ui.reference.inheritance: '継承'
ui.reference.inheritedMembers: '継承されたメンバー'
ui.reference.interfaces: 'インターフェイス'
@@ -584,7 +551,7 @@ ui.reference.values: '値'
ui.search.close: '検索を閉じる'
ui.search.empty: '「{query}」に一致する結果は見つかりませんでした。'
ui.search.hint: 'チュートリアル、概念、サンプル、API リファレンスを検索します。'
-ui.search.loading: '検索を読み込み中…'
+ui.search.loading: '検索機能を読み込み中…'
ui.search.more: 'さらに結果を表示'
ui.search.pending: '検索中…'
ui.search.placeholder: '何をお探しですか?'
diff --git a/documents/locales/ja-JP/translation.md b/documents/locales/ja-JP/translation.md
index cfc3ef31..b852d796 100644
--- a/documents/locales/ja-JP/translation.md
+++ b/documents/locales/ja-JP/translation.md
@@ -65,6 +65,8 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
## 用語
+DirectX 12、Metal 4、Vulkan 1.4 は「グラフィックス API」と呼び、対応するコードやパッケージは「各 API 向けの実装」と表現します。
+
| 英語 | 使用する表現 |
| ---------------- | ----------------------------------------------------------------------------------------------- |
| API / GPU / RHI | 略語を維持し、原文に従って説明する |
@@ -73,6 +75,7 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
| command buffer | コマンドバッファー |
| command queue | コマンドキュー |
| drawable | 現在のフレームの出力テクスチャ。`Drawable` は変更せず、常にスワップチェーンの画像とは解釈しない |
+| graphics API | グラフィックス API |
| graphics context | グラフィックスコンテキスト |
| pipeline | パイプライン |
| readback | リードバック |
diff --git a/documents/locales/ko-KR/strings.yml b/documents/locales/ko-KR/strings.yml
index 5396aadf..c283ccba 100644
--- a/documents/locales/ko-KR/strings.yml
+++ b/documents/locales/ko-KR/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: '{graphicsContext}는 특정 백엔드를 통해 애플리케이션을 GPU 장치에 연결하고 그래픽스, 컴퓨트, 전송 큐를 제공합니다. 함께 사용하는 리소스는 같은 컨텍스트에 속해야 합니다. 버퍼, 텍스처, 셰이더, 파이프라인과 그 핸들은 서로 다른 컨텍스트 사이에서 바인딩할 수 없습니다.'
+concepts.execution.context.description: '{graphicsContext}는 선택한 그래픽스 API를 통해 애플리케이션을 GPU 장치에 연결하고 그래픽스, 컴퓨트, 전송 큐를 제공합니다. 함께 사용하는 리소스는 같은 컨텍스트에 속해야 합니다. 버퍼, 텍스처, 셰이더, 파이프라인과 그 핸들은 서로 다른 컨텍스트 사이에서 바인딩할 수 없습니다.'
concepts.execution.context.details: '{capabilities}는 장치 이름과 지원 기능을 알려 줍니다. 해당 기능의 리소스를 만들기 전에 {rayTracingSupported}와 {meshShadingSupported}로 지원 여부를 확인합니다. {link} 및 {detail} 예제는 초기화 과정에서 이 검사를 수행합니다.'
concepts.execution.context.details.detail: 메시 셰이딩
concepts.execution.context.details.link: 레이 트레이싱
@@ -26,10 +26,10 @@ concepts.execution.pipelines.guidance.detail: '컴퓨트 예제'
concepts.execution.pipelines.guidance.link: 삼각형의 렌더링 콜백
concepts.execution.pipelines.title: '파이프라인 상태'
concepts.execution.queues.description: '그리기, 계산, 복사를 한 프레임에서 수행한다면 일반적으로 {graphicsQueue}부터 사용합니다. 서로 의존하는 작업을 한 큐에 두면 순서를 관리하기 쉽습니다.'
-concepts.execution.queues.details: '큐를 나누면 독립적인 작업을 각각 제출할 수 있지만, 각 큐가 반드시 독립된 하드웨어 엔진에 대응하는 것은 아닙니다. 작업을 겹쳐 실행할 때 이점이 있다면 추가 큐를 사용합니다. 한 큐가 다른 큐에서 만든 데이터를 사용한다면 두 제출 사이에 의존성을 명시합니다.'
+concepts.execution.queues.details: '독립적인 작업을 겹쳐 실행할 수 있다면 추가 큐가 유용할 수 있습니다. 다만 큐가 각각 독립된 하드웨어 엔진에 대응하는 것은 아닙니다. 한 큐가 다른 큐에서 만든 데이터를 사용한다면 두 제출 사이에 의존성을 명시합니다.'
concepts.execution.queues.guidance: '한 큐 안에서도 뒤의 접근이 앞서 쓴 데이터를 볼 수 있도록 배리어나 텍스처 전환이 필요할 수 있습니다. 이러한 메모리 의존성은 제출 순서와 구별됩니다. 구체적인 표현 방법은 {link} 문서에서 설명합니다.'
concepts.execution.queues.guidance.link: 동기화
-concepts.execution.queues.table.computeQueue.workToRecord: '그래픽 렌더 패스를 제외한 컴퓨트 디스패치 및 호환 가능한 전송 작업.'
+concepts.execution.queues.table.computeQueue.workToRecord: '그래픽스 렌더 패스를 제외한 컴퓨트 디스패치 및 호환 가능한 전송 작업.'
concepts.execution.queues.table.graphicsQueue.workToRecord: '렌더 패스, 그리기, 컴퓨트 및 전송 작업.'
concepts.execution.queues.table.headings.queue: 큐
concepts.execution.queues.table.headings.workToRecord: '지원 작업'
@@ -41,18 +41,16 @@ concepts.execution.recording.details: '삼각형 튜토리얼은 {commandBuffer}
concepts.execution.recording.guidance: '기록은 명령 시퀀스를 구성하고, {submit}은 그 시퀀스의 실행을 예약합니다. 이어서 {wait}를 호출하면 해당 제출이 끝날 때까지 CPU 스레드가 대기합니다. 튜토리얼에서는 각 프레임이 끝난 뒤 다음 프레임을 시작하므로 실행 흐름을 쉽게 따라갈 수 있습니다.'
concepts.execution.recording.title: '명령 기록과 제출'
concepts.execution.title: 실행 모델
-concepts.platforms.description: '화면 표시는 애플리케이션이나 UI 컨트롤이 관리합니다. 이 선택에 따라 프레임의 출력 텍스처를 얻고 명령을 기록·제출하며 결과를 표시할 주체가 정해집니다. 이 출력 텍스처를 drawable이라고 합니다.'
-concepts.platforms.frame.context: '패스 안에서 파이프라인 바인딩과 그리기 명령을 기록하고, 핸들러가 반환하기 전에 패스를 끝냅니다. 명령 제출과 결과 표시는 컨트롤이 담당합니다. 핸들러는 명령 버퍼를 직접 제출하거나 제공받은 두 객체를 해제해서는 안 됩니다. 출력 텍스처의 레이아웃을 바꿨다면 반환 전에 {colorAttachment}로 복원해 컨트롤이 마지막 전환을 수행할 수 있도록 합니다.'
+concepts.platforms.description: '화면 표시는 애플리케이션이나 UI 렌더링 컨트롤이 관리합니다. 이 선택에 따라 프레임의 출력 텍스처를 얻고 명령을 기록·제출하며 결과를 표시할 주체가 정해집니다. 이 출력 텍스처를 drawable이라고 합니다.'
+concepts.platforms.frame.context: '패스 안에서 파이프라인 바인딩과 그리기 명령을 기록하고, 핸들러가 반환하기 전에 패스를 끝냅니다. 핸들러는 명령 버퍼를 직접 제출하거나 제공받은 두 객체를 해제해서는 안 됩니다. 출력 텍스처의 레이아웃을 바꿨다면 반환 전에 {colorAttachment}로 복원해 컨트롤이 마지막 전환을 수행할 수 있도록 합니다.'
concepts.platforms.frame.description: '컨트롤은 {iZenithView}를 구현합니다. 애플리케이션은 {graphicsContext}를 지정하고 {updateRequested}에서 장면을 갱신하며, {renderRequested}에서 전달받은 {renderEventArgs}로 명령을 기록합니다.'
concepts.platforms.frame.details: '매 프레임 컨트롤은 출력 텍스처와 명령 버퍼를 가져오고, 텍스처를 {colorAttachment}로 전환한 뒤 업데이트와 렌더링 핸들러를 호출합니다. 이어서 기록된 작업을 제출하고 프레임워크의 표시 방식으로 이미지를 화면에 표시합니다.'
concepts.platforms.frame.guidance: '파일에 {usingZenithNET} 구문을 추가합니다. {view}라는 {iZenithView} 인스턴스가 초기화되어 있고 그래픽스 컨텍스트가 할당되어 있다면, 다음 핸들러를 등록해 출력 텍스처를 지울 수 있습니다.'
concepts.platforms.frame.notes: '초기 전환은 {undefined}를 사용하므로 이전 이미지의 내용은 버릴 수 있습니다. 매 프레임 이미지 전체를 그리거나 지웁니다. 누적 결과나 캐시한 렌더링 결과는 애플리케이션이 소유한 텍스처에 보관한 뒤 컨트롤의 출력 텍스처에 그립니다.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat}은 이 통합들이 사용하는 기본 색상 형식을 제공합니다.'
concepts.platforms.frame.title: 'UI 컨트롤에서 렌더링'
concepts.platforms.integration.context: 'WinForms, WPF, Windows용 WinUI 통합은 Windows에서 실행됩니다. MAUI는 대상 플랫폼의 워크로드를 설치하고, {extensionsCs}에서처럼 {useZenithView}로 컨트롤 핸들러를 등록합니다.'
concepts.platforms.integration.description: '이벤트 인터페이스는 공통이지만 표시 방식은 프레임워크마다 다릅니다.'
-concepts.platforms.integration.details: '각 구현은 GPU 이미지를 UI에 전달하는 방식이 다릅니다. 비트맵 리드백은 표시 전에 픽셀을 CPU 메모리로 복사합니다. 공유 텍스처 상호 운용은 이 CPU 복사를 피하지만 GPU 복사와 동기화는 여전히 필요할 수 있습니다. 통합을 선택할 때는 공통 {renderRequested} 이벤트뿐 아니라 이 표시 경로도 고려합니다.'
-concepts.platforms.integration.guidance: 'NuGet으로 사용하는 UI 프레임워크의 통합 패키지를 추가합니다. Avalonia에는 {avaloniaPackage}를 사용합니다.'
+concepts.platforms.integration.details: 'UI 통합마다 GPU 이미지를 화면에 표시하는 방식이 다릅니다. 비트맵 리드백은 표시 전에 픽셀을 CPU 메모리로 복사합니다. 공유 텍스처 상호 운용은 이 복사를 피하지만 GPU 복사와 동기화가 필요할 수 있습니다. 공통 {renderRequested} 이벤트와 함께 표시 경로도 고려합니다.'
concepts.platforms.integration.table.avalonia.integration: Avalonia
concepts.platforms.integration.table.avalonia.presentation: 텍스처에 렌더링하고 픽셀을 {writeableBitmap}으로 다운로드합니다. {zenithViewCs} 및 {surfaceCs}를 참조하세요.
concepts.platforms.integration.table.headings.integration: 통합
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: '표시 방식'
concepts.platforms.integration.table.maui.integration: .NET MAUI
concepts.platforms.integration.table.maui.presentation: 'Android, iOS 및 Mac Catalyst에서는 네이티브 서피스를 사용하고 Windows에서는 공유 텍스처를 이용한 합성 방식을 사용합니다. {link}을 참조하세요.'
concepts.platforms.integration.table.maui.presentation.link: 플랫폼 구현
-concepts.platforms.integration.table.uno.integration: Uno 경로
+concepts.platforms.integration.table.uno.integration: Uno Platform
concepts.platforms.integration.table.uno.presentation: 픽셀을 {writeableBitmap}으로 다운로드합니다. {zenithViewUnoCs}를 참조하세요.
concepts.platforms.integration.table.winForms.integration: WinForms
concepts.platforms.integration.table.winForms.presentation: 컨트롤의 {hWND}에 대한 Zenith.NET 스왑 체인을 생성합니다. {zenithViewCs}를 참조하세요.
@@ -76,16 +74,16 @@ concepts.platforms.lifecycle.guidance: '애플리케이션이 소유한 깊이
concepts.platforms.lifecycle.guidance.link: 회전하는 큐브 렌더러
concepts.platforms.lifecycle.title: '스왑 체인의 크기와 수명'
concepts.platforms.ownership.description: '애플리케이션은 할당한 컨텍스트와 자체 렌더링 리소스를 소유하고, 컨트롤은 화면 표시 리소스를 소유합니다. 뷰의 {graphicsContext}가 바뀌면 스케줄러는 새 컨텍스트에 맞게 컨트롤 리소스를 다시 만듭니다. 애플리케이션의 파이프라인, 버퍼, 텍스처도 새 컨텍스트에서 다시 만들어야 합니다.'
-concepts.platforms.ownership.details: '렌더링 리소스를 교체하기 전에 뷰의 프레임 처리를 중단하고 해당 리소스를 사용하는 GPU 작업이 끝날 때까지 기다립니다. 그런 다음 이전 리소스나 컨텍스트를 해제합니다. 뷰를 제거할 때도 할당한 컨텍스트를 해제할 책임은 애플리케이션에 있습니다.'
+concepts.platforms.ownership.details: '렌더링 리소스를 교체하기 전에 뷰의 프레임 루프를 중단하고 해당 리소스를 사용하는 GPU 작업이 끝날 때까지 기다립니다. 그런 다음 이전 리소스를 해제합니다. 모든 뷰가 해당 컨텍스트의 화면 표시 리소스를 해제하고, 그 컨텍스트에서 만든 애플리케이션 리소스도 모두 해제된 뒤에만 컨텍스트를 해제합니다.'
concepts.platforms.ownership.guidance: '공통 {frameSchedulerCs}는 뷰의 UI 디스패처를 통해 프레임 핸들러를 실행합니다. 핸들러에서는 장면 데이터 갱신과 명령 기록에 집중합니다. 여기서 CPU 작업이 오래 걸리면 인터페이스의 응답도 지연됩니다.'
concepts.platforms.ownership.title: '애플리케이션과 컨트롤의 소유권'
concepts.platforms.surface.description: '{link}은 Silk.NET으로 창을 만들고 이벤트를 처리합니다. Zenith.NET은 네이티브 창 핸들과 크기를 {surface} 설명으로 전달받아 {swapChain}을 만듭니다. 운영체제 창의 관리는 애플리케이션이 계속 맡습니다.'
concepts.platforms.surface.description.link: '삼각형 튜토리얼'
-concepts.platforms.surface.details: '서피스 핸들은 선택한 백엔드와 일치해야 합니다.'
+concepts.platforms.surface.details: '서피스 핸들은 그래픽스 API와 창 시스템에 따라 다릅니다. 일반적인 조합은 다음과 같습니다.'
concepts.platforms.surface.guidance: '{appCs}의 예제 호스트는 Windows, macOS, X11을 지원합니다. Linux 창에서 Xlib 핸들을 제공하므로 Wayland 세션에서 실행하려면 XWayland가 필요합니다. 네이티브 Wayland 애플리케이션은 {surfaceWayland}로 디스플레이와 서피스 핸들을 전달합니다.'
concepts.platforms.surface.table.android.backend: Android의 Vulkan.
concepts.platforms.surface.table.apple.backend: Apple 플랫폼의 Metal.
-concepts.platforms.surface.table.headings.backend: '백엔드와 플랫폼'
+concepts.platforms.surface.table.headings.backend: '그래픽스 API와 플랫폼'
concepts.platforms.surface.table.headings.factory: 서피스 팩토리
concepts.platforms.surface.table.headings.handles: 호스트에서 제공하는 핸들
concepts.platforms.surface.table.wayland.backend: 네이티브 Wayland 호스트를 사용하는 Vulkan.
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: '네이티브 표시 서피스'
concepts.platforms.title: 플랫폼 통합
concepts.resources.allocation.context: '힙에 배치한 리소스는 수명 내내 그 힙의 저장 공간에 의존합니다. GPU의 마지막 사용이 끝난 뒤 리소스를 먼저 해제하고 힙을 해제합니다.'
concepts.resources.allocation.description: '애플리케이션이 메모리 할당을 직접 관리해야 한다면 {heap}을 사용합니다. 힙은 리소스를 지정한 바이트 오프셋에 배치할 저장 공간을 제공합니다. 오프셋을 선택하고 어느 영역이 사용 중인지 추적하는 일은 애플리케이션이 맡습니다.'
-concepts.resources.allocation.details: '리소스를 만들 때 사용할 버퍼 또는 텍스처 설명으로 {contextGetSizeAndAlignment}를 호출합니다. 반환된 정렬 값의 배수인 오프셋에 반환된 크기만큼 공간을 확보하되, 힙의 범위를 벗어나거나 아직 사용 중인 다른 할당과 겹치지 않도록 합니다. 텍스처에는 백엔드별 패딩이 포함될 수 있으므로 픽셀 수와 픽셀당 바이트 수만으로 할당 크기를 계산할 수 없습니다.'
+concepts.resources.allocation.details: '리소스를 만들 때 사용할 버퍼 또는 텍스처 설명으로 {contextGetSizeAndAlignment}를 호출합니다. 반환된 정렬 값의 배수인 오프셋에 반환된 크기만큼 공간을 확보하되, 힙의 범위를 벗어나거나 아직 사용 중인 다른 할당과 겹치지 않도록 합니다. 텍스처에는 패딩이 포함될 수 있으므로 픽셀 수와 픽셀당 바이트 수만으로 할당 크기를 계산할 수 없습니다.'
concepts.resources.allocation.guidance: '힙에 배치하는 버퍼의 상주 특성은 힙과 같아야 합니다. 텍스처를 저장할 때는 GPU 전용 힙을 사용합니다.'
concepts.resources.allocation.title: '힙에 리소스 배치'
concepts.resources.bufferUsages.table.constant.role: 상수 버퍼 바인딩을 통해 읽는 셰이더 매개 변수.
@@ -105,7 +103,7 @@ concepts.resources.bufferUsages.table.headings.role: '역할'
concepts.resources.bufferUsages.table.headings.usage: 용도
concepts.resources.bufferUsages.table.index.role: '인덱스 그리기에 사용되는 인덱스.'
concepts.resources.bufferUsages.table.indirect.role: '간접 그리기 또는 디스패치 명령이 읽는 인수.'
-concepts.resources.bufferUsages.table.none.role: '버퍼 용도 플래그를 선언하지 않음.'
+concepts.resources.bufferUsages.table.none.role: '버퍼 용도 플래그를 선언하지 않습니다.'
concepts.resources.bufferUsages.table.storageReadOnly.role: '읽기 전용 셰이더 바인딩으로 접근하는 버퍼 데이터.'
concepts.resources.bufferUsages.table.storageReadWrite.role: '읽기 및 쓰기 셰이더 바인딩으로 접근하는 버퍼 데이터.'
concepts.resources.bufferUsages.table.transferDst.role: 'GPU 복사의 대상 저장 공간.'
@@ -124,7 +122,7 @@ concepts.resources.memory.table.cpuWriteOnly.typicalRole: 'CPU가 제공하거
concepts.resources.memory.table.gpuOnly.cPUAccess: '없음'
concepts.resources.memory.table.gpuOnly.typicalRole: '정적 지오메트리와 GPU 작업 데이터'
concepts.resources.memory.table.headings.cPUAccess: '의도한 CPU 접근'
-concepts.resources.memory.table.headings.residency: '상주 방식'
+concepts.resources.memory.table.headings.residency: '상주 특성'
concepts.resources.memory.table.headings.typicalRole: 일반적인 역할
concepts.resources.memory.title: 'CPU 접근과 메모리 배치'
concepts.resources.textureUsages.description: '전송 플래그는 리소스가 GPU 복사의 원본인지 대상인지를 나타냅니다. CPU가 저장 공간에 직접 접근할 수 있는지는 별도로 메모리 배치를 선택할 때 정합니다.'
@@ -134,7 +132,7 @@ concepts.resources.textureUsages.table.colorAttachment.role: '렌더 패스의
concepts.resources.textureUsages.table.depthStencilAttachment.role: '렌더 패스의 깊이/스텐실 어태치먼트.'
concepts.resources.textureUsages.table.headings.role: '역할'
concepts.resources.textureUsages.table.headings.usage: 용도
-concepts.resources.textureUsages.table.none.role: '텍스처 용도 플래그를 선언하지 않음.'
+concepts.resources.textureUsages.table.none.role: '텍스처 용도 플래그를 선언하지 않습니다.'
concepts.resources.textureUsages.table.sampled.role: '샘플링 텍스처 바인딩을 통해 읽는 텍스처 데이터.'
concepts.resources.textureUsages.table.storage.role: '스토리지 텍스처 바인딩을 통해 셰이더가 읽거나 쓰는 텍스처 데이터.'
concepts.resources.textureUsages.table.transferDst.role: 'GPU 복사의 대상 이미지 저장 공간.'
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: '업로드는 CPU 데이터를 GPU 리
concepts.resources.transfers.details: '이 메서드들을 호출하기 전에 다른 큐의 충돌하는 접근을 정리해야 합니다. 메서드 내부의 대기는 자체 전송만 대상으로 하며 다른 큐와의 의존성을 설정하지 않습니다. 매핑된 메모리로 직접 복사하는 경로에서는 충돌하는 GPU 접근을 기다리는 일도 전적으로 호출자가 담당합니다.'
concepts.resources.transfers.guidance: '전송을 다른 GPU 작업과 함께 제출하려면 {commandBufferUpload} 또는 {commandBufferDownload}로 기록합니다. 업로드 원본과 다운로드 대상은 메모리를 유효하게 유지해야 하는 기간이 서로 다릅니다.'
concepts.resources.transfers.item: '업로드를 호출하면 라이브러리가 원본 데이터를 임시 전송 공간인 스테이징 메모리에 복사합니다. 이후 GPU는 이 공간에서 읽으므로 애플리케이션의 원본 포인터는 호출이 반환할 때까지만 필요합니다.'
-concepts.resources.transfers.notes: '텍스처 전송에서 행 스트라이드는 CPU 데이터의 인접한 행 사이의 바이트 거리이고, 슬라이스 스트라이드는 인접한 깊이 슬라이스 사이의 거리입니다. 이 값으로 CPU에 배치된 데이터와 GPU의 텍스처 저장 공간 사이를 복사할 수 있습니다. GPU 복사 완료와 다운로드 대상에 데이터가 전달되는 시점이 다른 이유는 {link} 문서에서 설명합니다.'
-concepts.resources.transfers.notes.link: 동기화
+concepts.resources.transfers.layouts: '명령 버퍼에 기록하는 텍스처 전송에는 레이아웃 전환이 포함되지 않습니다. 업로드에는 {copyDst}, 다운로드에는 {copySrc}가 필요합니다. 복사 전에 해당 레이아웃으로의 전환을 기록하고, 복사 후에는 다음 용도에 필요한 레이아웃으로의 전환을 기록합니다.'
+concepts.resources.transfers.notes: '텍스처 전송에서 행 스트라이드는 CPU 데이터의 인접한 행 사이의 바이트 거리이고, 슬라이스 스트라이드는 인접한 깊이 슬라이스 사이의 거리입니다. 이 값으로 CPU에 배치된 데이터와 GPU의 텍스처 저장 공간 사이를 복사할 수 있습니다.'
concepts.resources.transfers.table.bufferDownload.transfer: '{cpuReadOnly}이면 매핑된 메모리에서 직접 복사합니다. 그 외에는 전송 큐에 다운로드를 제출하고 완료를 기다립니다.'
concepts.resources.transfers.table.bufferUpload.transfer: '{cpuWriteOnly}이면 매핑된 메모리에 직접 복사합니다. 그 외에는 전송 큐에 업로드를 제출하고 완료를 기다립니다.'
concepts.resources.transfers.table.headings.method: '메서드'
concepts.resources.transfers.table.headings.transfer: '전송 동작'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: '복사와 텍스처 전환을 그래픽스 큐에 제출한 뒤 완료를 기다립니다. 선택한 하위 리소스는 요청한 최종 레이아웃으로 남습니다.'
-concepts.resources.transfers.title: '즉시 전송과 기록된 전송'
+concepts.resources.transfers.title: '즉시 전송과 명령 버퍼에 기록하는 전송'
concepts.resources.usages.description: '{bufferUsages}와 {textureUsages}는 리소스 용도를 선언하는 플래그 열거형입니다. 각각 {bufferDescUsages}와 {textureDescUsages}에 지정합니다. 여러 용도가 필요하면 {value}로 해당 멤버를 결합합니다.'
concepts.resources.usages.title: '리소스 용도'
-concepts.resources.views.description: '{bufferView}는 버퍼의 영역과 그 데이터를 해석하는 방식을 기술합니다. {textureView}는 하위 리소스 범위를 선택하고, 호환되는 텍스처 유형과 포맷을 지정합니다. 둘 다 기존 저장 공간을 참조하며, 생성 시 선언한 용도를 따릅니다. 뷰 범위는 접근 대상을 기술하지만 모든 백엔드에서 동일한 셰이더 범위 검사를 보장하지는 않습니다.'
+concepts.resources.views.description: '{bufferView}는 버퍼의 영역과 그 데이터를 해석하는 방식을 기술합니다. {textureView}는 하위 리소스 범위를 선택하고, 호환되는 텍스처 유형과 포맷을 지정합니다. 둘 다 기존 저장 공간을 참조하며, 생성 시 선언한 용도를 따릅니다. 뷰 범위는 접근 대상을 기술하지만 셰이더에서 일관된 범위 검사를 보장하지는 않습니다.'
concepts.resources.views.details: '리소스 자체의 핸들은 기본 뷰를 제공합니다. 다른 영역이나 호환되는 다른 해석 방식이 필요하면 별도 뷰를 만듭니다. GPU가 사용을 마칠 때까지 뷰와 원본 리소스를 모두 유지해야 합니다. 핸들만으로는 어느 객체의 수명도 유지되지 않습니다. 둘 중 하나를 교체하면 이전 {link}이 들어 있는 상수도 갱신합니다.'
concepts.resources.views.details.link: '리소스 핸들'
concepts.resources.views.title: '뷰와 원본 리소스'
concepts.shaders.binding.context: '컴퓨트 예제는 {input}에 {inputTextureSampledHandle}을, {output}에 {outputTextureStorageHandle}을 지정합니다. Slang의 {descriptorHandle} 형식 인수가 각 리소스의 셰이더 접근 방식을 정합니다.'
concepts.shaders.binding.description: '{setConstantBuffer}는 현재 파이프라인이 상수를 읽을 버퍼와 시작 바이트 오프셋을 선택합니다. 셰이더가 사용하기 전에 해당 공간에 매개변수를 업로드합니다. 이전 GPU 작업이 같은 바이트를 아직 읽고 있다면 그 작업이 끝난 뒤 데이터를 갱신합니다.'
concepts.shaders.binding.details: '명령 버퍼, 컴퓨트 파이프라인, 데이터가 채워진 상수 버퍼, 스레드 그룹 수를 준비한 뒤 다음 순서로 디스패치를 기록합니다. 상수 버퍼 바인딩은 현재 파이프라인에 적용되므로 파이프라인을 먼저 선택합니다.'
-concepts.shaders.binding.guidance: '여기서 {commandBuffer}는 {computePipeline}을 사용하는 디스패치를 기록합니다. 셰이더 매개변수는 {constantBuffer}에 저장되어 있습니다. 버퍼에는 {bufferUsagesConstant} 용도가 필요하고, 오프셋 0은 버퍼의 시작을 선택합니다. 여러 상수 레코드가 한 버퍼를 공유한다면 각 레코드의 시작 오프셋도 백엔드의 바인딩 정렬을 따라야 합니다. 이는 레코드 내부의 필드 배치와 별개의 조건입니다.'
-concepts.shaders.binding.notes: '{resourceHandle}은 32비트 필드 두 개를 포함하며 해석은 백엔드에 따라 다릅니다. 이 값은 리소스를 생성한 컨텍스트에서만 유효합니다.'
+concepts.shaders.binding.guidance: '상수 버퍼에는 {bufferUsagesConstant} 용도가 필요합니다. 여러 상수 레코드가 한 버퍼를 공유한다면 각 레코드의 시작 오프셋은 필요한 바인딩 정렬을 충족해야 합니다. 이는 레코드 내부의 필드 배치와 별개의 조건입니다.'
+concepts.shaders.binding.notes: '{resourceHandle}은 32비트 필드 두 개를 포함하며 해석은 그래픽스 API에 따라 다릅니다. 이 값은 리소스를 생성한 컨텍스트에서만 유효합니다.'
concepts.shaders.binding.reference: '핸들을 얻은 리소스와 뷰는 셰이더의 마지막 접근이 끝날 때까지 유지합니다. 텍스처나 뷰를 교체하면 이전 핸들을 담은 상수를 갱신합니다. 소유권 규칙은 {link}에서 설명합니다.'
concepts.shaders.binding.reference.link: 리소스 관리
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: '셰이더 형식 {t}의 구조화 요소 읽기'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: '텍스처 샘플링 상태
concepts.shaders.binding.table.textureSampledHandle.access: '텍스처 읽기'
concepts.shaders.binding.table.textureStorageHandle.access: '스토리지 텍스처 읽기 및 쓰기'
concepts.shaders.binding.title: '상수 버퍼와 리소스 핸들'
-concepts.shaders.compilation.description: '{zenithCompiler}는 지정한 Slang 진입점을 {shaderDesc}로 컴파일합니다. 컨텍스트의 {graphicsApi}에 따라 DirectX 12용 DXIL, Metal 라이브러리, Vulkan용 SPIR-V를 생성합니다.'
+concepts.shaders.compilation.description: '{zenithCompiler}는 Slang 진입점을 컴파일하고 {shaderDesc}를 반환합니다. 컨텍스트의 {graphicsApi}가 출력 형식을 결정합니다. DirectX 12에는 {dxil}, Metal에는 {metallib}, Vulkan에는 {spirv}를 사용합니다.'
concepts.shaders.compilation.details: '{context}라는 그래픽스 컨텍스트를 이미 만든 상태에서, 실행 파일 옆에 복사해 둔 삼각형 셰이더를 다음과 같이 컴파일합니다.'
concepts.shaders.compilation.guidance: '진입점 이름 {vSMain}은 셰이더 파일의 선언과 일치해야 합니다. 초기화 중에 셰이더를 컴파일하고 파이프라인을 만든 뒤, 렌더링 중에는 파이프라인을 재사용합니다. 파이프라인 생성이 끝나면 셰이더 객체를 해제할 수 있습니다. {link} 튜토리얼에서 이 순서를 확인할 수 있습니다.'
concepts.shaders.compilation.guidance.link: 첫 번째 삼각형
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: '정점 입력에서 {inputLayout}은 각
concepts.shaders.layout.details: '상수 버퍼에는 셰이더 매개변수를, 구조화 버퍼에는 형식이 지정된 요소의 배열을 저장합니다. 이들의 배치는 {inputLayout}이 아니라 Slang 선언을 따릅니다. C#의 필드 오프셋, 요소 크기, 패딩을 컴파일된 셰이더 레이아웃에 맞춥니다. 관리되지 않는 C# 형식은 바이트로 복사할 수 있지만, 그 메모리 배치가 셰이더의 배치와 반드시 일치하는 것은 아닙니다. 정점에서 촘촘히 배치한 {float3}도 셰이더 버퍼에서는 다른 정렬이 필요할 수 있습니다.'
concepts.shaders.layout.guidance: '셰이더 매개변수에는 일반 값뿐 아니라 리소스 핸들도 포함할 수 있습니다. 핸들은 이미 존재하는 저장 공간을 가리키므로 상수 버퍼에 핸들을 복사해도 리소스의 내용까지 복사되지는 않습니다.'
concepts.shaders.layout.notes: '{computeShaderSlang}의 대응 선언은 다음과 같습니다.'
-concepts.shaders.layout.reference: '두 크기 값이 처음 8바이트를 차지하고, 그 뒤에 각각 8바이트인 핸들 두 개가 이어집니다. C# 예제는 전체 레코드에 256바이트를 확보합니다. 다른 레코드의 크기는 그 필드와 레이아웃 및 정렬 요구 사항에 맞춰 정합니다.'
+concepts.shaders.layout.reference: 'C# 필드는 처음 24바이트를 차지합니다. 크기 값에 총 8바이트, 각 핸들에 8바이트를 사용합니다. 256바이트 레코드의 나머지는 패딩입니다. 다른 매개변수 블록을 사용한다면 필드 오프셋을 해당 셰이더 레이아웃에 맞춥니다. 여러 레코드가 버퍼 하나를 공유할 때는 각 시작 위치가 필요한 바인딩 정렬을 충족하도록 레코드 사이에 충분한 패딩을 둡니다.'
concepts.shaders.layout.title: '데이터 배치'
concepts.shaders.matrices.description: '컴파일러는 각 행을 연속으로 저장하는 행 우선 행렬 배치를 사용합니다. {link}에서는 {matrix4x4} 세 개를 오프셋 0, 64, 128에 저장합니다. 해당 {detail}는 {mulVectorMatrix}를 모델, 뷰, 투영 순으로 적용합니다.'
concepts.shaders.matrices.description.detail: 셰이더
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: 회전하는 큐브 렌더러
concepts.shaders.matrices.details: '저장 순서는 메모리의 행렬 요소 배치를, 곱셈 순서는 변환을 정합니다. C#과 Slang에서 서로 맞는 규약을 사용해야 합니다.'
concepts.shaders.matrices.title: '행렬 규약'
concepts.shaders.title: 셰이더 데이터 및 바인딩
-concepts.synchronization.backends.description: 'DirectX 12와 Vulkan은 텍스처 전환을 레이아웃 및 접근 변경 명령으로 기록합니다. Metal에서는 Zenith.NET의 {transition} 구현이 이에 해당하는 GPU 작업을 수행하지 않습니다. 대신 Metal 백엔드는 명령을 렌더 인코더와 컴퓨트 인코더로 묶고 인코더가 끝날 때 가시성 배리어를 삽입합니다. 연속된 컴퓨트 디스패치처럼 같은 인코더 안에서 의존하는 작업에는 {barrier}를 명시적으로 호출합니다.'
-concepts.synchronization.backends.details: '{link}에서는 그래픽스 렌더 패스를 시작하면서 컴퓨트 인코더를 끝내므로 그래픽스 작업이 컴퓨트 결과를 볼 수 있습니다. 연속된 두 컴퓨트 디스패치는 같은 인코더에 남아 있으므로 중간에 텍스처 전환을 기록하더라도 의존성을 위한 배리어가 필요합니다. 여러 백엔드에서 사용할 명령 시퀀스는 이처럼 텍스처 레이아웃과 접근 의존성을 함께 고려해야 합니다.'
+concepts.synchronization.backends.description: 'DirectX 12와 Vulkan은 텍스처 전환을 레이아웃 및 접근 변경 명령으로 기록합니다. Metal에서는 Zenith.NET의 {transition} 구현이 이에 해당하는 GPU 작업을 수행하지 않습니다. 대신 Metal용 구현은 명령을 렌더 인코더와 컴퓨트 인코더로 묶고 인코더가 끝날 때 가시성 배리어를 삽입합니다. 연속된 컴퓨트 디스패치처럼 같은 인코더 안에서 의존하는 작업에는 {barrier}를 명시적으로 호출합니다.'
+concepts.synchronization.backends.details: '{link}에서는 그래픽스 렌더 패스를 시작하면서 컴퓨트 인코더를 끝내므로 그래픽스 작업이 컴퓨트 결과를 볼 수 있습니다. 연속된 두 컴퓨트 디스패치는 같은 인코더에 남아 있으므로 중간에 텍스처 전환을 기록하더라도 의존성을 위한 배리어가 필요합니다.'
concepts.synchronization.backends.details.link: '컴퓨트 예제'
-concepts.synchronization.backends.title: '백엔드별 동작'
+concepts.synchronization.backends.title: '그래픽스 API별 동기화'
concepts.synchronization.barriers.context: '관련 접근을 포함하고 큐에서 지원하는 단계를 선택합니다. {barrierStagesAll}은 지원되는 모든 단계를 포함합니다. 의존성이 일부 단계에만 관련된다면 해당 단계만 선택합니다.'
concepts.synchronization.barriers.description: '같은 명령 버퍼에 두 컴퓨트 디스패치를 기록한다고 가정합니다. 첫 번째는 시뮬레이션 데이터를 쓰고 두 번째는 이를 읽습니다. 두 번째가 완료된 쓰기를 볼 수 있도록 디스패치 사이에 배리어를 둡니다. 스토리지 버퍼라면 텍스처 레이아웃을 전환하지 않고 다음과 같이 접근 순서를 정할 수 있습니다.'
concepts.synchronization.barriers.details: '첫 번째 인수는 데이터를 만든 단계를, 두 번째는 데이터를 사용할 단계를 지정합니다. 두 인수는 디스패치 사이에 필요한 실행 순서와 메모리 가시성을 기술합니다.'
-concepts.synchronization.barriers.guidance: '{link}은 시뮬레이션 단계 사이에 이 패턴을 적용합니다. 각 배리어는 데이터를 만드는 디스패치 뒤, 이를 사용하는 디스패치 앞에 놓입니다.'
+concepts.synchronization.barriers.guidance: '{link}은 시뮬레이션 단계 사이에 이 패턴을 적용합니다.'
concepts.synchronization.barriers.guidance.link: FluidTank 시뮬레이션
concepts.synchronization.barriers.title: '파이프라인 배리어'
-concepts.synchronization.dependencies.description: '각 리소스에서 같은 데이터를 다루는 접근을 확인합니다. 어느 한쪽이라도 쓰기라면 필요한 순서를 지켜야 합니다. 읽기끼리는 충돌하지 않지만 텍스처 레이아웃과 프레젠테이션 요구 사항은 여전히 적용됩니다. CPU가 데이터를 갱신하거나 리소스를 해제할 때도 GPU가 해당 저장 공간을 다 쓸 때까지 기다려야 합니다.'
+concepts.synchronization.dependencies.description: '각 리소스에서 같은 데이터를 다루는 접근을 확인합니다. 어느 한쪽이라도 쓰기라면 필요한 순서를 지켜야 합니다. 읽기끼리는 충돌하지 않지만 텍스처 레이아웃과 화면 표시 요구 사항은 여전히 적용됩니다. CPU가 데이터를 갱신하거나 리소스를 해제할 때도 GPU가 해당 저장 공간을 다 쓸 때까지 기다려야 합니다.'
concepts.synchronization.dependencies.details: '작업이 실행되는 위치에 따라 적절한 수단을 선택합니다.'
-concepts.synchronization.dependencies.guidance: '한 작업에 여러 동기화 수단이 필요할 수 있습니다. 예를 들어 다른 큐에서 만든 텍스처를 사용하려면 제출 간 의존성과 다음 용도에 맞는 레이아웃이 모두 필요합니다. CPU가 직접 데이터에 접근하거나 메모리를 해제해야 하는 경우가 아니라면 이 두 작업 때문에 CPU를 대기시킬 필요는 없습니다.'
+concepts.synchronization.dependencies.guidance: '한 큐가 쓴 텍스처를 다른 큐에서 사용한다면 제출 간 의존성을 지정하고 필요한 레이아웃 전환을 기록합니다. 두 작업은 CPU를 대기시키지 않습니다. CPU가 데이터에 접근하거나 리소스를 해제하기 전에는 완료를 기다립니다.'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: 해당 완료 값에 대해 {wait}를 호출합니다.
concepts.synchronization.dependencies.table.cpuAccess.situation: 'CPU 접근이나 리소스 해제에 GPU 완료가 필요'
concepts.synchronization.dependencies.table.crossQueue.mechanism: '생산자의 {timelineValue}를 소비자의 {submit}에 전달합니다.'
@@ -227,8 +225,8 @@ concepts.synchronization.dependencies.table.pipelineStages.situation: 명령 스
concepts.synchronization.dependencies.title: '접근 의존 관계'
concepts.synchronization.description: '동기화는 공유 데이터에 접근하는 순서를 정하고, 뒤의 작업이 필요한 결과를 볼 수 있게 합니다. 쓰기에서 읽기로 이어지는 의존성에서 쓰는 작업을 생산자, 읽는 작업을 소비자라고 합니다. 배리어와 텍스처 전환은 GPU 접근을 조율하며, 타임라인은 제출 간 의존성을 연결하고 CPU가 GPU 완료를 기다릴 수 있게 합니다.'
concepts.synchronization.layouts.context: '새 이미지나 전체를 지울 어태치먼트처럼 기존 내용을 버려도 되는 경우 이전 레이아웃에 {undefined}를 사용합니다. 로드, 샘플링, 누적에 기존 내용이 필요하다면 직전 접근의 레이아웃을 지정합니다.'
-concepts.synchronization.layouts.description: '용도 플래그는 텍스처에 허용된 역할을 선언합니다. {textureLayout}은 밉 레벨과 배열 레이어로 식별한 하위 리소스를 명령 시퀀스의 특정 지점에서 어떻게 접근하는지 나타냅니다. 접근 방식이 바뀌면 전환을 기록합니다. 예를 들어 컴퓨트 예제는 출력 텍스처를 {storage} 레이아웃에서 쓴 뒤 그래픽스 패스에서 샘플링할 수 있도록 준비합니다.'
-concepts.synchronization.layouts.details: '여기서는 {outputTexture}를 {sampledStorage} 용도로 만들었고 선택한 하위 리소스는 {storage} 상태입니다. {default}는 mip 레벨 0과 배열 레이어 0을 선택합니다. 다른 레벨이나 레이어에는 영향을 주지 않습니다.'
+concepts.synchronization.layouts.description: '용도 플래그는 텍스처에 허용된 역할을 선언합니다. {textureLayout}은 밉 레벨과 배열 레이어로 식별한 하위 리소스에 명령 시퀀스의 특정 지점에서 어떻게 접근하는지를 나타냅니다. 접근 방식이 바뀌면 전환을 기록합니다. 예를 들어 컴퓨트 예제는 출력 텍스처를 {storage} 레이아웃에서 쓴 뒤 그래픽스 패스에서 샘플링할 수 있도록 준비합니다.'
+concepts.synchronization.layouts.details: '여기서는 {outputTexture}를 {sampledStorage} 용도로 만들었고 선택한 하위 리소스의 레이아웃은 {storage}입니다. {default}는 mip 레벨 0과 배열 레이어 0을 선택합니다. 다른 레벨이나 레이어에는 영향을 주지 않습니다.'
concepts.synchronization.layouts.guidance: '{transition}에는 하위 리소스의 직전 사용 레이아웃을 전달합니다. 애플리케이션은 명령을 기록하고 렌더링 단계 사이에 텍스처를 전달하면서 이 상태를 추적합니다.'
concepts.synchronization.layouts.title: '텍스처 레이아웃'
concepts.synchronization.readback.description: '{isCompleted}는 GPU 완료 여부를 알려 줍니다. 기록된 다운로드에는 내부 리드백 공간의 결과를 애플리케이션의 대상 메모리로 복사하는 단계가 하나 더 있습니다.'
@@ -256,7 +254,7 @@ home.entries.reference.category: 참조
home.entries.reference.description: 'API 형식, 멤버, 선언 찾아보기'
home.entries.reference.title: API 참조
home.entries.samples.action: 예제 탐색
-home.entries.samples.category: 예제
+home.entries.samples.category: 코드 예제
home.entries.samples.description: '직접 실행하며 살펴보는 그래픽스와 컴퓨트 예제'
home.entries.samples.title: 예제
home.entries.title: '문서'
@@ -265,9 +263,9 @@ home.entries.tutorial.category: 튜토리얼
home.entries.tutorial.description: '빈 프로젝트에서 첫 삼각형을 그리기까지'
home.entries.tutorial.title: 첫 번째 삼각형
home.introduction.accent: '크로스 플랫폼 그래픽스'
-home.introduction.description: 'Zenith.NET은 DirectX, Metal, Vulkan의 그래픽스와 컴퓨트 기능을 하나의 API로 제공합니다'
+home.introduction.description: 'Zenith.NET은 DirectX 12, Metal 4, Vulkan 1.4 전반에서 그래픽스와 컴퓨트를 위한 단일 API를 제공합니다'
home.introduction.title: '.NET으로 만드는{lineBreak}{accent}'
-home.meta.description: 'DirectX, Metal, Vulkan의 공통 API로 개발하는 .NET 크로스 플랫폼 그래픽스·컴퓨트 애플리케이션'
+home.meta.description: 'DirectX 12, Metal 4, Vulkan 1.4에 공통 API를 제공하는 .NET 크로스 플랫폼 그래픽스·컴퓨트 라이브러리'
home.scene.description: '회전하는 도형을 조작할 수 있습니다. 드래그하거나 방향키를 눌러 시점을 바꾸세요.'
home.scene.label: 지오메트리 표시
home.scene.surface: 서피스
@@ -290,71 +288,65 @@ learning.title: 학습
reference.description: '리소스, 명령, 플랫폼 통합 참조'
reference.entries.commands.description: '그래픽스, 컴퓨트, 전송 명령'
reference.entries.commands.label: '명령 기록'
-reference.entries.context.description: '선택한 백엔드의 GPU 리소스 생성'
+reference.entries.context.description: '그래픽스 컨텍스트를 통한 GPU 리소스 생성'
reference.entries.context.label: 여기서 시작
reference.meta.description: 'Zenith.NET 네임스페이스, 형식, 멤버'
reference.navigation.core: '핵심 API 참조'
reference.title: API 참조
-samples.computeShader.description: '이 예제는 {assetsTexturesShokoPng}를 읽고 컴퓨트 디스패치에서 회색조로 변환한 뒤 결과 텍스처를 표시합니다. 변환은 한 번만 실행하고 이후 프레임은 같은 결과를 표시합니다. 렌더러는 샘플링용 텍스처와 쓰기 가능한 텍스처를 바인딩하고, 스레드 그룹 수를 올림해 이미지 전체를 처리하며, 셰이더에서 이미지 범위를 확인하는 방법을 보여 줍니다.'
+samples.computeShader.description: '컴퓨트 셰이더가 컬러 이미지를 회색조로 변환해 GPU 이미지 처리를 보여 줍니다.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: '컴퓨트 셰이더'
-samples.cube.description: '큐브는 인덱스 그리기, 상수 버퍼의 모델·뷰·투영 행렬, 깊이 테스트를 추가합니다. {d32FloatS8UInt} 깊이·스텐실 텍스처는 크기를 바꿀 때 다시 생성합니다.'
+samples.cube.description: '회전하는 큐브로 인덱스 지오메트리, 3D 변환, 깊이 테스트를 소개합니다.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: 회전하는 큐브
-samples.description: '각 예제는 C# 렌더러와 Slang 셰이더를 함께 제공하며 한 가지 기법을 다룹니다. 애플리케이션 구성부터 렌더링까지의 전체 과정은 {link}에서 설명합니다.'
-samples.description.link: 첫 번째 삼각형
+samples.description: '삼각형 하나를 그리는 예제부터 인터랙티브 애플리케이션과 진단 도구까지, 렌더링과 컴퓨트 예제를 소개합니다.'
samples.execution.description: '{link} 프로젝트를 실행하고 콘솔 메뉴에서 예제를 선택합니다.'
samples.execution.description.link: ZenithTutorials
samples.execution.title: '예제 실행'
-samples.host.description: '{appCs}는 컨텍스트, 창, 스왑 체인을 초기화합니다. 매 프레임 명령 버퍼를 얻고 선택한 렌더러를 호출한 다음 명령을 제출하고 결과를 표시합니다. {iRendererCs}는 갱신, 렌더링, 크기 변경, 해제 작업을 정의합니다.'
-samples.host.details: '컴퓨트 렌더러와 레이 트레이싱 렌더러는 오프스크린 텍스처를 만듭니다. {texturePresenterCs}와 {presentTextureSlang}이 이 텍스처를 현재 출력 텍스처에 그리면, 공통 호스트가 명령을 제출하고 프레임을 화면에 표시합니다.'
-samples.host.title: '호스트와 화면 표시'
-samples.indirectDrawing.description: '간접 그리기는 인덱스 그리기 인수 버퍼와 인스턴스별 구조화 데이터 버퍼로 여러 큐브를 그립니다. CPU가 인수를 제공하고 변환을 갱신합니다.'
+samples.indirectDrawing.description: '색이 서로 다른 큐브들이 격자에서 회전하며, 그리기 인수 버퍼를 사용하는 간접 그리기를 보여 줍니다.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: '간접 그리기'
-samples.meshShading.description: '태스크 셰이더가 구 인스턴스를 컬링하고 남은 인덱스를 메시 셰이더에 전달하면 메시 셰이더가 지오메트리를 생성합니다. 파이프라인 생성 전에 {contextCapabilitiesMeshShadingSupported}를 확인합니다.'
+samples.meshShading.description: '이 예제는 태스크 셰이더와 메시 셰이더를 사용해 카메라 시야 밖의 구를 제외하면서 색상이 있는 구를 격자 형태로 렌더링합니다. 메시 셰이딩 지원이 필요합니다.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: 메시 셰이딩
-samples.rayTracing.description: '바닥과 절차적 구의 하위·상위 가속 구조를 만들고 컴퓨트 셰이더에서 인라인 레이 쿼리를 수행합니다. 초기화 전에 {contextCapabilitiesRayTracingSupported}를 확인합니다.'
+samples.rayTracing.description: '이 예제는 레이 쿼리로 바둑판무늬 바닥 위에 주변을 반사하는 구와 그림자를 렌더링합니다. 레이 트레이싱 지원이 필요합니다.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: 레이 트레이싱
samples.title: 예제
-samples.triangle.description: '정점 버퍼와 대응하는 입력 레이아웃을 연결하고 그래픽스 파이프라인으로 정점 세 개를 그립니다.'
+samples.triangle.description: '정점 색상이 부드럽게 이어지는 삼각형으로 그래픽스 파이프라인의 기초를 소개합니다.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: 전체 튜토리얼
samples.triangle.title: Hello Triangle
-samples.workloads.description: '주 저장소의 {link}에는 라이브러리 소스를 참조하는 더 큰 규모의 애플리케이션이 있습니다.'
+samples.workloads.description: 'Zenith.NET 저장소의 {link}에는 다음 애플리케이션과 도구가 있습니다.'
samples.workloads.description.link: Experiments 디렉터리
-samples.workloads.details: '창을 사용하는 실험은 동일한 Windows, macOS, Linux/X11 표시 경로를 사용합니다. Avalonia, WinForms, WPF, WinUI/Uno, MAUI 컨트롤의 프레임 흐름과 구현 소스는 {link}에서 설명합니다.'
-samples.workloads.details.link: 플랫폼 통합
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: CornellBox
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '패스 트레이싱, 디노이징, 톤 매핑, 업스케일링, ImGui 컨트롤을 다룹니다. 레이 트레이싱 지원이 필요합니다.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '조명과 반사를 살펴볼 수 있는 인터랙티브 실내 장면입니다. 레이 트레이싱 지원이 필요합니다.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: FluidTank
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '컴퓨트 유체 시뮬레이션, 시뮬레이션 단계 사이의 의존 관계, 다중 패스 표면 렌더링을 다룹니다.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '수면 또는 입자 형태로 볼 수 있는 수조 속 물 시뮬레이션입니다.'
samples.workloads.table.headings.example: 예제
-samples.workloads.table.headings.whatItDemonstratesAndRequires: '기법과 요구 사항'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: '설명'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: InkCanvas
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '네이티브 창에서의 Skia 그리기 및 입력 처리를 보여줍니다. 대상 플랫폼용 백엔드 및 네이티브 Skia 라이브러리가 필요합니다.'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '자유롭게 선을 그리고 지울 수 있는 캔버스입니다.'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: PlatformDetection
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '각 백엔드의 컨텍스트 생성을 시도하고 장치 기능을 보고합니다. 생성에 실패하면 지원되지 않는 것으로 표시하지만, 원인은 장치나 드라이버 또는 누락된 런타임 의존성일 수 있습니다.'
-samples.workloads.title: '복합 렌더링 애플리케이션'
-tutorial.context.description: '{graphicsContext}는 백엔드를 통해 애플리케이션을 GPU에 연결하고 렌더링 리소스를 만드는 메서드를 제공합니다.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '그래픽스 API 사용 가능 여부와 장치 기능을 알려 주는 콘솔 도구입니다.'
+samples.workloads.title: '애플리케이션과 도구'
+tutorial.context.description: '{graphicsContext}는 선택한 그래픽스 API를 통해 애플리케이션을 GPU에 연결하고 렌더링 리소스를 만드는 메서드를 제공합니다.'
tutorial.context.details: '컨텍스트 초기화를 {emphasis}에 추가합니다.'
tutorial.context.details.emphasis: using 지시문 뒤, {iWindowWindow} 앞
-tutorial.context.guidance: '각 분기에서 플랫폼에 맞는 백엔드를 선택하고 검증을 요청합니다. {validationMessage} 메시지는 콘솔에 출력합니다.'
+tutorial.context.guidance: '각 분기는 선택한 그래픽스 API의 검증을 요청합니다. 구현이 {validationMessage} 진단 메시지를 제공하면 핸들러가 이를 콘솔에 출력합니다.'
tutorial.context.imports: '{programCs} 맨 위에 다음 using 지시문을 추가합니다.'
tutorial.context.title: '그래픽스 컨텍스트'
tutorial.description: '이 튜토리얼에서는 빈 .NET 콘솔 프로젝트에서 시작해 창을 열고 색상이 있는 삼각형을 그리는 애플리케이션을 만듭니다.'
tutorial.details: '튜토리얼에는 세 번의 확인 단계가 있습니다. 먼저 빈 창을 열고, 단색 배경을 표시한 다음, 색상이 있는 삼각형을 그립니다. 각 단계에서 애플리케이션을 실행해 결과를 확인한 뒤 다음 부분을 추가합니다.'
tutorial.draw.context: '{draw}의 인수는 다음과 같습니다.'
tutorial.draw.description: '{windowRender} 콜백의 {addTheTriangleDrawCommandsHereLater}를 다음 명령으로 바꿉니다. 위치는 {beginRenderPass}와 {endRenderPass} 사이입니다.'
-tutorial.draw.details: '{setPipeline}은 셰이더와 렌더링 상태를 선택합니다. 정점 바인딩은 파이프라인의 입력 레이아웃으로 해석되므로, 그 전에 호출해야 합니다.'
+tutorial.draw.details: '{setPipeline}은 셰이더와 렌더링 상태를 선택합니다. 정점 버퍼를 바인딩하기 전에 파이프라인을 선택합니다. 파이프라인의 입력 레이아웃이 정점 데이터를 읽는 방식을 결정하기 때문입니다.'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer}는 업로드한 정점 데이터를 바이트 오프셋 0부터 입력 슬롯 0에 바인딩합니다. 이 슬롯은 {inputLayouts}의 유일한 항목과 대응합니다.'
-tutorial.draw.notes: '이 호출들은 그리기 명령을 기록합니다. 기존의 {submitWait}가 명령을 제출하고 GPU 완료를 기다리면, {present}가 완성된 이미지의 표시를 요청합니다. 삼각형 바깥 영역에도 배경색이 정해지도록 패스 시작 부분의 지우기 작업을 유지합니다.'
+tutorial.draw.notes: '삼각형 바깥 영역에도 배경색이 정해지도록 패스 시작 부분의 지우기 작업을 유지합니다.'
tutorial.draw.table.firstInstance.meaning: 인스턴스 번호 매기기를 0부터 시작합니다.
tutorial.draw.table.firstVertex.meaning: 버퍼의 첫 번째 정점부터 시작합니다.
tutorial.draw.table.headings.argument: 인수
@@ -370,25 +362,25 @@ tutorial.execution.title: '애플리케이션 실행'
tutorial.frame.commands.context: '{endRenderPass} 뒤의 두 번째 전환은 출력 텍스처를 화면에 표시할 수 있도록 준비합니다. {submit}은 기록을 끝내고 명령 버퍼를 제출하며, {wait}는 해당 제출이 완료될 때까지 CPU 스레드를 대기시킵니다. 이어서 {present}가 렌더링한 이미지의 표시를 요청합니다.'
tutorial.frame.commands.description: '렌더 패스는 같은 어태치먼트에 쓰는 그리기 작업을 묶습니다. 이 패스에서는 스왑 체인의 출력 텍스처가 색상 결과를 받습니다. {colorAttachmentClear}는 해당 어태치먼트를 RGBA 색상으로 초기화하고 패스가 끝난 뒤에도 내용을 보존하도록 지정합니다. {beginRenderPass}는 이 설정으로 패스를 시작하는 명령을 기록합니다.'
tutorial.frame.commands.details: '컬렉션에는 색상 어태치먼트 하나가 있습니다. {null}은 이 패스에 깊이·스텐실 어태치먼트가 없다는 뜻입니다.'
-tutorial.frame.commands.guidance: '{beginRenderPass}는 어태치먼트 전체를 덮도록 뷰포트와 시저를 설정합니다. 뷰포트는 렌더링 좌표를 픽셀 위치로 바꾸고 시저는 쓸 수 있는 영역을 제한합니다.'
+tutorial.frame.commands.guidance: '{beginRenderPass}는 어태치먼트 전체를 덮도록 뷰포트와 시저를 설정합니다. 뷰포트는 렌더링 좌표를 픽셀 위치로 바꾸고 시저는 그리기 작업이 영향을 줄 수 있는 픽셀 범위를 제한합니다.'
tutorial.frame.commands.title: '지우기, 제출, 표시'
-tutorial.frame.description: '먼저 창을 하나의 배경색으로 채웁니다. 이 작업을 지우기라고 합니다. 배경색이 보이면 서피스, 명령 제출, 표시 과정이 연결된 것입니다. 이제 삼각형의 정점과 셰이더를 추가할 수 있습니다.'
-tutorial.frame.details: 'Silk.NET은 프레임을 그릴 시점에 콜백을 호출합니다. 이 예제는 경과 시간 인수를 쓰지 않으므로 매개변수 이름을 {value}로 둡니다. 콜백을 {emphasis}에 등록합니다.'
+tutorial.frame.description: '먼저 창을 단색으로 채웁니다. 이를 지우기라고 합니다. 색상이 보이면 명령 제출과 화면 표시가 작동하는 것입니다. 다음으로 삼각형의 정점과 셰이더를 추가합니다.'
+tutorial.frame.details: 'Silk.NET은 프레임을 그릴 시점에 렌더링 콜백을 호출합니다. 콜백을 {emphasis}에 등록합니다.'
tutorial.frame.details.emphasis: '{windowRun} 앞'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer}는 기록할 준비가 된 명령 버퍼를 반환합니다. 기록은 GPU 작업을 정의하는 단계이며 실행은 제출 후 시작됩니다.'
+tutorial.frame.target.description: '명령 큐는 GPU에서 실행할 기록된 명령을 받습니다. {graphicsQueueCommandBuffer}는 이미 기록이 시작된 명령 버퍼를 반환합니다. 기록된 명령이 GPU 작업을 정의하며 실행은 제출 후 시작됩니다.'
tutorial.frame.target.details: '텍스처 레이아웃은 작업에 필요한 접근 방식을 나타냅니다. 첫 번째 {transition} 호출은 출력 텍스처를 색상 어태치먼트로 사용할 수 있도록 준비합니다. 여기서 {default}는 출력 텍스처의 기본 이미지인 밉 레벨 0과 배열 레이어 0을 선택합니다. 이 패스는 이미지 전체를 지우므로 {undefined}를 지정해 이전 내용을 버릴 수 있습니다.'
tutorial.frame.target.guidance: '화면에 표시한 뒤에는 다른 이미지로 넘어갈 수 있으므로 매 프레임 현재 출력 텍스처를 가져옵니다.'
tutorial.frame.target.title: '출력 텍스처 준비'
tutorial.frame.title: '첫 프레임'
tutorial.geometry.data.description: '정점 배열을 {emphasis}에 추가합니다. 이후 리소스 초기화도 설명한 순서대로 이 콜백 앞에 둡니다.'
tutorial.geometry.data.description.emphasis: '{windowRender} 앞'
-tutorial.geometry.data.details: '각 항목은 {vertex}를 생성하고, 안쪽의 두 {new} 표현식은 {vector3} 위치와 {vector4} 색상을 제공합니다. 위치는 위, 오른쪽 아래, 왼쪽 아래 꼭짓점입니다. 정점 셰이더는 네 번째 좌표를 {w}로 설정합니다. w가 1이므로 x와 y는 정규화 장치 좌표이기도 하며, -1과 +1은 이미지 경계, 0은 중앙을 뜻합니다. 이 해석은 픽셀 크기와 무관합니다.'
+tutorial.geometry.data.details: '세 위치는 위, 오른쪽 아래, 왼쪽 아래 꼭짓점에 해당합니다. 이 예제에서 x와 y는 이미지 전체에 걸쳐 -1부터 +1까지의 범위를 사용합니다. 0은 중심이며, x의 양의 방향은 오른쪽, y의 양의 방향은 위쪽입니다.'
tutorial.geometry.data.guidance: '각 색상은 빨강, 초록, 파랑, 알파 성분을 가지며 알파는 1입니다. 세 정점 모두 z = 0인 같은 평면에 있습니다.'
tutorial.geometry.data.title: '정점 위치와 색상'
tutorial.geometry.description: '세 정점은 각각 위치와 색상을 가집니다. GPU는 위치로 삼각형 모양을 정하고 정점 색상을 보간해 내부의 색상을 계산합니다.'
tutorial.geometry.format.description: '정점 선언을 {emphasis}에 추가합니다.'
tutorial.geometry.format.description.emphasis: '{programCs} 끝부분, 정리 문 뒤'
-tutorial.geometry.format.details: '{file}은 형식의 사용 범위를 {programCs}로 제한하고, {layoutKindSequential}은 필드를 선언 순서대로 배치합니다. {position}은 32비트 부동소수점 값 세 개로 구성되며 바이트 오프셋 0에서 시작합니다. {color}는 네 개로 구성되며 바이트 오프셋 12에서 시작합니다. 따라서 정점 하나는 28바이트입니다. GPU가 각 필드를 올바르게 읽을 수 있도록 입력 레이아웃에 이 배치를 기술합니다.'
+tutorial.geometry.format.details: '{layoutKindSequential}은 필드를 선언 순서대로 배치합니다. {position}은 32비트 부동소수점 값 세 개로 구성되며 바이트 오프셋 0에서 시작합니다. {color}는 네 개로 구성되며 바이트 오프셋 12에서 시작합니다. 따라서 정점 하나는 28바이트입니다. GPU가 각 필드를 올바르게 읽을 수 있도록 입력 레이아웃에 이 배치를 기술합니다.'
tutorial.geometry.format.imports: '벡터 형식과 구조체 레이아웃 특성을 사용하도록 {programCs} 맨 위에 다음 using 지시문을 추가합니다.'
tutorial.geometry.format.title: '정점 표현'
tutorial.geometry.title: '정점 데이터'
@@ -397,8 +389,7 @@ tutorial.geometry.upload.description: 'GPU가 그리기 중에 읽을 수 있도
tutorial.geometry.upload.details: '할당 크기는 {sizeofVertexVerticesLength}로, 28바이트 정점 세 개인 84바이트입니다. {bufferUsagesVertex}는 정점 입력 접근을 선언하고 {cpuWriteOnly}는 CPU 직접 초기화를 허용합니다. 설명의 스트라이드는 요소 크기이며, 뒤에서 정의할 입력 레이아웃이 각 속성을 읽는 방법을 정합니다.'
tutorial.geometry.upload.guidance: '할당만으로 버퍼 내용이 초기화되지는 않습니다. {upload}는 데이터 설명의 원본 포인터와 바이트 수를 사용해 배열을 목적지 오프셋 0에 복사합니다.'
tutorial.geometry.upload.imports: 'Zenith.NET 버퍼 형식을 {systemBuffer}와 구분하기 위해 {programCs}의 using 지시문에 {bufferAlias} 구문을 추가합니다.'
-tutorial.geometry.upload.notes: '{programCs} 끝의 해제 코드에서 {swapChainDispose} 바로 앞에 {vertexBufferDispose}를 추가합니다. 큰 정적 지오메트리를 위한 GPU 전용 저장과 전송은 {link}에서 설명합니다.'
-tutorial.geometry.upload.notes.link: 리소스 관리
+tutorial.geometry.upload.notes: '{programCs} 끝의 해제 코드에서 {swapChainDispose} 바로 앞에 {vertexBufferDispose}를 추가합니다.'
tutorial.geometry.upload.title: '버퍼 할당과 업로드'
tutorial.input.description: 'GPU는 위치와 색상 같은 정점 속성이 어디에 있는지 알아야 합니다. 입력 레이아웃은 각 속성의 포맷과 바이트 오프셋을 지정합니다. 스트라이드는 다음 정점까지의 바이트 거리입니다. 셰이더를 생성한 뒤 다음 코드를 추가합니다.'
tutorial.input.details: '{inputLayoutAdd}는 각 속성을 이전 속성 바로 뒤에 배치하고 그 크기를 정점 간 스트라이드에 더합니다. 오프셋은 C# 구조체를 조사하는 대신 여기서 지정한 형식으로 계산합니다. 두 필드의 배치는 다음과 같습니다.'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: 다음 입력 레코드
tutorial.input.table.vertexColor.format: '{float4} (16바이트)'
tutorial.input.table.vertexPosition.format: '{float3} (12바이트)'
tutorial.input.title: '정점 입력 레이아웃'
-tutorial.lifecycle.description: '각 프레임은 다음 순서를 따릅니다.'
-tutorial.lifecycle.details: '창을 닫으면 {run}이 반환하고 정리 코드가 이어서 실행됩니다. 각 프레임에서 제출한 작업이 끝날 때까지 이미 기다렸으므로 명령에 사용한 리소스를 해제할 수 있습니다. {windowRun} 뒤에 들어갈 전체 정리 코드는 다음과 같습니다.'
+tutorial.lifecycle.description: '각 프레임에서 현재 출력 텍스처를 가져와 렌더링용으로 전환한 뒤 지우고 삼각형을 그립니다. 이어서 표시용으로 전환하고 명령을 제출해 완료를 기다린 뒤 이미지를 표시합니다.'
+tutorial.lifecycle.details: '창을 닫으면 {run}이 반환하고 정리 코드가 이어서 실행됩니다. 렌더링 콜백이 제출된 모든 프레임의 완료를 기다렸으므로 명령에 사용한 리소스를 해제할 수 있습니다. {windowRun} 뒤에 들어갈 전체 정리 코드는 다음과 같습니다.'
tutorial.lifecycle.guidance: '네이티브 창을 파괴하기 전에 스왑 체인을 해제하고, 컨텍스트는 그 리소스들을 해제한 뒤 정리합니다. 제출한 명령 버퍼는 큐가 재사용하고 출력 텍스처는 스왑 체인이 관리하므로 각각 {dispose}를 호출할 필요가 없습니다.'
-tutorial.lifecycle.title: '프레임 흐름과 해제'
tutorial.pipeline.behavior: '입력 레이아웃 다음에 파이프라인을 생성합니다.'
tutorial.pipeline.context: '{cullNone}은 면 컬링을 끕니다. 따라서 정점이 시계 방향으로 보이든 반시계 방향으로 보이든 삼각형을 그립니다.'
tutorial.pipeline.description: '{graphicsPipeline}은 정점 레이아웃, 두 셰이더, 프리미티브 조립과 어태치먼트 출력 설정을 하나로 묶습니다.'
-tutorial.pipeline.details: '셰이더는 정점과 프래그먼트를 처리합니다. 나머지 파이프라인 설정은 프리미티브 조립, 면 컬링, 깊이 테스트, 색상 블렌딩을 제어합니다.'
tutorial.pipeline.guidance: '파이프라인의 색상 포맷은 렌더 패스의 어태치먼트와 같아야 하므로 {swapChainDescFormat}에서 가져옵니다. {count1}은 픽셀당 샘플 하나를 지정합니다.'
tutorial.pipeline.item: '{triangleList}는 연속된 정점 세 개를 한 삼각형으로 조립합니다.'
tutorial.pipeline.notes: '{depthNone}은 깊이 테스트와 쓰기를 끕니다. 깊이 어태치먼트가 없는 패스와 일치하는 설정입니다.'
@@ -428,28 +417,25 @@ tutorial.pipeline.reference: '{opaque}는 블렌딩을 끕니다. 따라서 프
tutorial.pipeline.title: '그래픽스 파이프라인'
tutorial.pipeline.usage: '셰이더 객체는 파이프라인을 생성한 뒤 해제할 수 있습니다. 파이프라인은 렌더링 동안 유지하고, 해제 코드에서 {vertexBufferDispose} 앞에 {pipelineDispose}를 추가합니다.'
tutorial.presentation.title: '그래픽스 컨텍스트와 표시'
-tutorial.project.context: '프로젝트 빌드 설정에서 {emphasis}({allowUnsafeBlocks})를 켭니다. 창 보조 코드의 네이티브 호출과 정점 업로드에는 unsafe 코드가 필요합니다.'
+tutorial.project.context: '프로젝트 빌드 설정에서 {emphasis}({allowUnsafeBlocks})를 켭니다. 창 보조 클래스의 네이티브 호출과 정점 업로드에는 unsafe 코드가 필요합니다.'
tutorial.project.context.emphasis: 안전하지 않은 코드 허용
tutorial.project.description: '.NET 10을 대상으로 하는 {firstTriangle} C# 콘솔 프로젝트를 만듭니다.'
tutorial.project.details: '다음 NuGet 패키지를 프로젝트에 추가합니다.'
-tutorial.project.guidance: '{zenithNET}은 공통 렌더링 API를, 백엔드 패키지 세 개는 플랫폼 구현을 제공합니다. {zenithNETCompiler}는 뒤에서 작성할 Slang 셰이더를 선택한 백엔드에 맞게 컴파일합니다. Silk.NET은 창 생성과 이벤트 처리를 담당합니다.'
+tutorial.project.guidance: '{zenithNET}은 그래픽스와 컴퓨트를 위한 공통 API를 제공하고, 그래픽스 API별 패키지 세 개가 이를 구현합니다. {zenithNETCompiler}는 선택한 API에 맞게 Slang 셰이더를 컴파일합니다.'
tutorial.project.title: '프로젝트 준비'
-tutorial.requirements.context: '{link}와 해당 {detail}에서 이 튜토리얼의 참조 구현을 확인할 수 있습니다.'
-tutorial.requirements.context.detail: 공유 호스트
-tutorial.requirements.context.link: 'Hello Triangle 예제'
-tutorial.requirements.description: '{emphasis}와 기본 C# 지식이 필요합니다. 애플리케이션의 대상 프레임워크는 {net10}입니다. GPU와 드라이버는 사용 중인 플랫폼에 맞춰 선택한 다음 백엔드를 지원해야 합니다.'
+tutorial.requirements.description: '{emphasis}와 기본 C# 지식이 필요합니다. GPU와 드라이버는 플랫폼에 맞는 다음 그래픽스 기능을 지원해야 합니다.'
tutorial.requirements.description.emphasis: .NET 10 SDK
-tutorial.requirements.guidance: 'Zenith.NET은 애플리케이션이 제공하는 네이티브 서피스에 렌더링합니다. Silk.NET.Windowing은 창을 만들고 이벤트를 처리합니다. macOS에서는 {cAMetalLayerCs}로 표현되는 Metal 레이어로 표시하며, 창 보조 코드가 이 레이어를 창에 연결합니다.'
-tutorial.requirements.table.headings.graphicsBackend: 그래픽 백엔드
+tutorial.requirements.guidance: 'Zenith.NET은 애플리케이션이 제공하는 네이티브 서피스에 렌더링합니다. Silk.NET.Windowing은 창을 만들고 이벤트를 처리합니다.'
+tutorial.requirements.table.headings.graphicsBackend: '그래픽스 지원 조건'
tutorial.requirements.table.headings.platform: 플랫폼
-tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 및 VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux(X11 또는 XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: Metal 4
tutorial.requirements.table.macOS.platform: macOS
-tutorial.requirements.table.windows.graphicsBackend: DirectX 12
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 및 Shader Model 6.6'
tutorial.requirements.table.windows.platform: Windows
tutorial.requirements.title: '준비 사항'
-tutorial.resize.context: '애플리케이션을 다시 빌드하고 실행합니다. 창 크기를 바꿔도 배경이 창 전체를 채워야 합니다. 새 렌더 패스를 시작할 때마다 변경된 어태치먼트 크기로 뷰포트와 시저가 설정되기 때문입니다. 렌더링 콜백은 그대로 둡니다. 이후 이 패스 안에서 삼각형을 그립니다.'
+tutorial.resize.context: '애플리케이션을 다시 빌드하고 실행합니다. 창 크기를 바꿔도 배경이 창 전체를 채워야 합니다. 렌더링 콜백은 그대로 둡니다. 이후 이 패스 안에서 삼각형을 그립니다.'
tutorial.resize.description: '프레임버퍼 크기가 바뀌면 스왑 체인도 그에 맞춰야 합니다. 렌더링 콜백 뒤, {windowRun} 앞에 {framebufferResize} 콜백을 등록합니다.'
tutorial.resize.details: '창의 논리적 크기 대신 픽셀 단위의 {link}을 처리합니다. 창을 최소화하면서 너비나 높이가 0이 되면 크기 변경 콜백은 스왑 체인을 그대로 둡니다. 렌더링 콜백도 어느 한쪽이 0인 동안에는 바로 반환하므로, 프레임버퍼가 다시 유효한 크기가 될 때까지 렌더링이 중단됩니다.'
tutorial.resize.details.link: 프레임버퍼 크기 변경
@@ -458,54 +444,36 @@ tutorial.resize.guidance.link: 동기화
tutorial.resize.title: '크기 변경'
tutorial.shaders.compilation.context: '{appContextBaseDirectory}를 사용하면 애플리케이션 출력 디렉터리에 복사한 셰이더를 불러옵니다. 다른 작업 디렉터리에서 애플리케이션을 실행하더라도 셰이더를 찾는 위치는 바뀌지 않습니다.'
tutorial.shaders.compilation.description: '{triangleSlang}의 파일 속성에서 {emphasis}를 {detail}로 설정합니다. 빌드하면 셰이더가 실행 파일 옆으로 복사됩니다.'
-tutorial.shaders.compilation.description.detail: 변경된 내용만 복사
+tutorial.shaders.compilation.description.detail: 원본 파일이 더 최신이면 복사
tutorial.shaders.compilation.description.emphasis: 출력 디렉터리에 복사
-tutorial.shaders.compilation.details: '{programCs}로 돌아와 정점 업로드 뒤, 렌더 콜백 앞에 셰이더 초기화를 추가합니다.'
+tutorial.shaders.compilation.details: '{programCs}로 돌아와 정점 업로드 뒤, 렌더링 콜백 앞에 셰이더 초기화를 추가합니다.'
tutorial.shaders.compilation.guidance: '{zenithCompiler}는 {contextGraphicsApi}에 맞게 소스를 컴파일하고, {createShader}는 컴파일 결과의 설명으로 셰이더 객체를 만듭니다. 진입점 이름 {vSMain}과 {fSMain}은 Slang 파일에 정의한 두 함수를 선택합니다.'
tutorial.shaders.compilation.title: '셰이더 컴파일'
tutorial.shaders.context: '{fSInput}은 두 셰이더 단계를 연결합니다. 정점 셰이더는 {sVPOSITION}에 클립 공간 위치를 기록하며, GPU는 이 위치를 이용해 삼각형에서 보이는 부분을 결정합니다. {cOLOR0} 필드는 정점 색상을 전달합니다. 이 색상은 삼각형 내부에서 보간된 뒤 프래그먼트 셰이더에 전달되므로 두 단계의 필드 형식과 시맨틱이 일치해야 합니다.'
tutorial.shaders.description: '셰이더는 GPU에서 실행하는 프로그램입니다. 정점 셰이더는 각 정점의 위치를 정하고, 프래그먼트 셰이더는 이미지에서 도형이 덮는 각 위치의 색상을 정합니다. 두 단계를 하나의 Slang 파일에 작성하되, 실행을 시작하는 함수인 진입점은 단계별로 따로 둡니다.'
-tutorial.shaders.details: '{triangleSlang}을 만들고 다음 입력·출력 구조체를 작성합니다.'
+tutorial.shaders.details: '프로젝트 루트에 {triangleSlang}을 만들고 다음 입력·출력 구조체를 작성합니다.'
tutorial.shaders.fragment.description: '같은 파일에 프래그먼트 진입점을 추가합니다.'
tutorial.shaders.fragment.details: '래스터화는 삼각형이 이미지의 어느 위치를 덮는지 결정하고 해당 위치에 프래그먼트를 생성합니다. 각 프래그먼트는 세 정점의 색상으로부터 보간된 색상을 받습니다. {fSMain}은 이 색상을 반환하고, {sVTARGET}은 결과를 첫 번째 색상 어태치먼트로 보냅니다.'
tutorial.shaders.fragment.title: '프래그먼트 셰이더'
tutorial.shaders.guidance: '{vSInput}은 정점 셰이더의 입력을 정의합니다. {pOSITION0}과 {cOLOR0}이 시맨틱으로 속성을 식별하며, C# 필드 이름만으로는 이 대응 관계가 정해지지 않습니다.'
tutorial.shaders.title: '셰이더 단계'
tutorial.shaders.vertex.description: '{triangleSlang}에 정점 진입점을 추가합니다.'
-tutorial.shaders.vertex.details: 'GPU는 입력 정점마다 이 함수를 실행합니다. 함수는 네 번째 동차 좌표를 {w}로 설정하고 색상을 그대로 전달합니다. 정점 처리 후 위치를 w로 나누는데, 여기서는 1이므로 x, y, z가 그대로 유지되어 정규화 장치 좌표로 해석됩니다.'
+tutorial.shaders.vertex.details: 'GPU는 입력 정점마다 이 함수를 실행합니다. 위치에 네 번째 성분을 추가해 {w}로 설정하고 색상을 그대로 전달합니다. 정점 처리 후 GPU는 x, y, z를 w로 나누어 정규화 장치 좌표를 구합니다. 여기서는 w가 1이므로 값이 변하지 않습니다.'
tutorial.shaders.vertex.title: '정점 셰이더'
tutorial.surface.description: '네이티브 표시 대상을 {emphasis}에 지정합니다.'
tutorial.surface.description.emphasis: '{windowCenter} 뒤, {windowRun} 앞'
tutorial.surface.details: '프레임버퍼는 창에 표시할 픽셀 이미지입니다. {surface}는 네이티브 표시 대상과 크기를 설명하고 {framebufferSize}는 픽셀 단위 크기를 제공합니다. 화면 배율에 따라 창의 논리 크기와 다를 수 있습니다.'
-tutorial.surface.guidance: '서피스는 백엔드가 요구하는 네이티브 핸들을 제공합니다. Windows에서는 Win32 창, Linux에서는 X11 디스플레이와 창, macOS에서는 연결한 Metal 레이어를 사용합니다.'
+tutorial.surface.guidance: '서피스는 선택한 그래픽스 API에서 필요한 네이티브 핸들을 제공합니다. Windows에서는 Win32 창, Linux에서는 X11 디스플레이와 창, macOS에서는 연결한 Metal 레이어를 사용합니다.'
tutorial.surface.title: '네이티브 서피스'
tutorial.swapChain.context: '스왑 체인은 컨텍스트와 창 모두에 의존합니다. {programCs} 끝의 {windowDispose}를 다음 해제 순서로 바꿉니다.'
tutorial.swapChain.description: '서피스 설명 바로 다음에 스왑 체인을 생성합니다.'
tutorial.swapChain.details: '{swapChain}은 창에 표시할 이미지를 관리합니다. {drawable}은 현재 이미지를 API의 이미지 리소스인 {texture}로 제공합니다. 렌더링 후 {present}가 이미지 표시를 요청하고 다음 출력 텍스처로 넘어갑니다.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm}은 파랑, 초록, 빨강, 알파 순서로 8비트 채널 네 개를 저장합니다. {uNorm}은 정수 0–255를 0–1에 대응시킵니다. 셰이더 출력은 논리적인 RGBA 값이며, 포맷은 메모리에 저장하는 방식을 정합니다. 파이프라인의 색상 포맷은 {swapChainDescFormat}을 사용해 어태치먼트와 맞춥니다.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm}은 파랑, 초록, 빨강, 알파 순서로 8비트 채널 네 개를 저장합니다. {uNorm}은 정수 0–255를 0–1에 대응시킵니다. 셰이더 출력은 논리적인 RGBA 값이며, 포맷은 메모리에 저장하는 방식을 정합니다.'
tutorial.swapChain.title: '스왑 체인'
tutorial.title: 첫 번째 삼각형
-tutorial.troubleshooting.description: '콘솔 진단과 세 단계의 결과를 이용해 문제가 생긴 지점을 찾습니다.'
-tutorial.troubleshooting.details: '{link}와 {detail}에서 정점 데이터, 입력 레이아웃, 그리기를 확인할 수 있습니다. 예제는 창과 제출을 공통 호스트로 분리하지만, 이 튜토리얼은 전체 흐름을 {programCs}에 둡니다. {context}에서는 인덱스 그리기, 변환, 깊이 테스트를 소개합니다.'
-tutorial.troubleshooting.details.context: 회전하는 큐브
-tutorial.troubleshooting.details.detail: Slang 셰이더
-tutorial.troubleshooting.details.link: '예제 렌더러'
-tutorial.troubleshooting.table.backend.check: 선택한 백엔드가 장치 및 설치된 그래픽 드라이버에서 지원되는지 확인합니다.
-tutorial.troubleshooting.table.backend.symptom: 백엔드 생성 실패
-tutorial.troubleshooting.table.drawing.check: '업로드 크기, 입력 레이아웃, 파이프라인 선택 및 렌더 패스 내부의 그리기 명령 배치를 확인합니다.'
-tutorial.troubleshooting.table.drawing.symptom: 배경은 나타나지만 삼각형은 나타나지 않음
-tutorial.troubleshooting.table.headings.check: 확인 사항
-tutorial.troubleshooting.table.headings.symptom: 증상
-tutorial.troubleshooting.table.input.check: '스트라이드가 28바이트이고 위치와 색상의 오프셋이 각각 0과 12바이트인지 확인합니다.'
-tutorial.troubleshooting.table.input.symptom: 정점 위치 또는 색상이 손상됨
-tutorial.troubleshooting.table.shaders.check: 복사된 {triangleSlang}, 진입점 철자 및 컴파일러에서 보고된 진단을 확인합니다.
-tutorial.troubleshooting.table.shaders.symptom: '배경색은 표시되지만 셰이더를 불러오지 못함'
-tutorial.troubleshooting.table.window.check: '.NET 프로젝트가 빌드되고 창 전용 단계가 데스크톱 세션에서 실행되는지 확인합니다. Linux의 경우 X11 또는 XWayland를 사용할 수 있는지 확인합니다.'
-tutorial.troubleshooting.table.window.symptom: '창이 열리지 않음'
-tutorial.troubleshooting.title: '문제 진단'
tutorial.window.description: '{cocoaHelperCs}를 다운로드해 프로젝트에 추가합니다. 이 보조 클래스는 macOS 창에 Metal 레이어를 연결합니다.'
-tutorial.window.details: '자동 생성된 {programCs} 내용을 다음 코드로 바꿉니다. 최상위 문을 사용하므로 {main} 메서드를 직접 작성하지 않아도 위에서 아래로 실행됩니다. 이후 각 절에서 새 코드를 넣을 위치를 안내합니다.'
-tutorial.window.guidance: '{graphicsAPINone}은 그래픽스 컨텍스트 생성을 Zenith.NET에 맡깁니다. {initialize}는 네이티브 창을 만들고 창 시스템 핸들을 사용할 수 있게 합니다. {center}는 창을 화면 가운데 놓습니다. {run}이 창을 닫을 때까지 이벤트를 처리한 뒤 {dispose}가 실행되어 창을 해제합니다.'
+tutorial.window.details: '{programCs} 내용을 다음 코드로 바꿉니다.'
+tutorial.window.guidance: '{graphicsAPINone}은 Silk.NET이 그래픽스 컨텍스트를 만들지 않도록 설정합니다. 이후 애플리케이션이 Zenith.NET 그래픽스 컨텍스트를 만듭니다. {initialize}는 네이티브 창을 만들고 창 시스템 핸들을 사용할 수 있게 합니다. {center}는 창을 화면 가운데 놓습니다. {run}이 창을 닫을 때까지 이벤트를 처리한 뒤 {dispose}가 실행되어 창을 해제합니다.'
tutorial.window.notes: '애플리케이션을 빌드하고 실행합니다. 창을 열고 닫을 수 있는지, 이동하거나 크기를 바꿀 수 있는지 확인합니다. 아직 렌더링 명령을 제출하지 않아 창 내부의 내용은 정의되지 않았습니다. 다음 단계로 넘어가기 전에 창을 닫습니다.'
tutorial.window.title: '창 생성'
ui.action.copy: 복사
@@ -525,7 +493,7 @@ ui.api.noNamespaceTypes: 이 네임스페이스에는 형식이 없습니다.
ui.api.noTypes: 일치하는 형식이 없습니다.
ui.api.types: 형식
ui.content.reference: 참조
-ui.content.source: 소스 코드
+ui.content.examples: 코드 예제
ui.content.tutorial: 튜토리얼
ui.contents.close: 목차 닫기
ui.contents.open: 목차 열기
@@ -545,7 +513,7 @@ ui.members.undeclared: 이 형식에는 선언된 멤버가 없습니다.
ui.navigation.api: API
ui.navigation.concepts: 개념
ui.navigation.home: 홈
-ui.navigation.label: 기본 탐색
+ui.navigation.label: 주 탐색
ui.navigation.skip: 본문으로 건너뛰기
ui.navigation.toggle: 탐색 전환
ui.outline.title: 이 페이지의 내용
@@ -562,7 +530,6 @@ ui.reference.exceptions: 예외
ui.reference.extensionMethods: 확장 메서드
ui.reference.fields: 필드
ui.reference.implementations: 명시적 인터페이스 구현
-ui.reference.implements: 구현
ui.reference.inheritance: 상속
ui.reference.inheritedMembers: 상속된 멤버
ui.reference.interfaces: 인터페이스
@@ -584,10 +551,10 @@ ui.reference.values: 값
ui.search.close: 검색 닫기
ui.search.empty: “{query}”에 대한 결과가 없습니다.
ui.search.hint: 튜토리얼, 개념, 예제 및 API 참조를 검색합니다.
-ui.search.loading: 검색 로드 중…
+ui.search.loading: 검색 기능을 불러오는 중…
ui.search.more: 결과 더 보기
ui.search.pending: 검색 중…
ui.search.placeholder: 무엇을 찾으시나요?
ui.search.resultCount: '결과: {count}개'
ui.search.title: 문서 검색
-ui.search.unavailable: 검색을 사용할 수 없습니다. 아래 페이지를 계속 열 수 있습니다.
+ui.search.unavailable: 검색을 사용할 수 없습니다. 아래 페이지는 열 수 있습니다.
diff --git a/documents/locales/ko-KR/translation.md b/documents/locales/ko-KR/translation.md
index d1fd58e3..e8eeb2e8 100644
--- a/documents/locales/ko-KR/translation.md
+++ b/documents/locales/ko-KR/translation.md
@@ -65,6 +65,8 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
## 용어
+DirectX 12, Metal 4, Vulkan 1.4는 "그래픽스 API"로, 이를 지원하는 코드와 패키지는 "각 API의 구현"으로 표현합니다.
+
| 영어 | 사용할 표현 |
| ---------------- | -------------------------------------------------------------------------------------- |
| API / GPU / RHI | 약어를 유지하고 원문에 따라 설명 |
@@ -73,6 +75,7 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
| command buffer | 명령 버퍼 |
| command queue | 명령 큐 |
| drawable | 현재 프레임의 출력 텍스처. `Drawable`은 유지하며 항상 스왑 체인 이미지로 해석하지 않음 |
+| graphics API | 그래픽스 API |
| graphics context | 그래픽스 컨텍스트 |
| pipeline | 파이프라인 |
| readback | 리드백 |
diff --git a/documents/locales/pt-BR/strings.yml b/documents/locales/pt-BR/strings.yml
index 065cd8fa..23f21c11 100644
--- a/documents/locales/pt-BR/strings.yml
+++ b/documents/locales/pt-BR/strings.yml
@@ -1,13 +1,13 @@
### YamlMime:Resources
-concepts.execution.context.description: 'Um {graphicsContext} conecta a aplicação a um dispositivo GPU por meio de um backend específico e fornece suas filas gráfica, de computação e de transferência. Recursos usados em conjunto devem pertencer ao mesmo contexto; buffers, texturas, shaders, pipelines e seus identificadores não podem ser vinculados entre contextos diferentes.'
+concepts.execution.context.description: 'Um {graphicsContext} conecta a aplicação a um dispositivo GPU por meio da API gráfica escolhida e fornece suas filas gráfica, de computação e de transferência. Recursos usados em conjunto devem pertencer ao mesmo contexto; buffers, texturas, shaders, pipelines e seus identificadores não podem ser vinculados entre contextos diferentes.'
concepts.execution.context.details: '{capabilities} informa o nome do dispositivo e as funcionalidades disponíveis. Consulte {rayTracingSupported} e {meshShadingSupported} antes de criar os recursos necessários a essas operações. Os exemplos de {link} e {detail} fazem essas verificações durante a inicialização.'
concepts.execution.context.details.detail: 'sombreamento de malha'
concepts.execution.context.details.link: 'traçado de raios'
concepts.execution.context.title: 'Contexto gráfico'
-concepts.execution.description: 'O trabalho da GPU é preparado na CPU: a aplicação cria recursos, registra comandos que os utilizam e envia esses comandos a uma fila. Após o envio, a CPU pode continuar enquanto a GPU executa o trabalho. Os recursos precisam permanecer disponíveis até o fim dessa execução.'
+concepts.execution.description: 'O trabalho da GPU começa na CPU: a aplicação cria recursos, grava os comandos que os utilizam e os envia a uma fila. Após o envio, a CPU pode continuar enquanto a GPU executa os comandos. Os recursos precisam permanecer disponíveis até o fim dessa execução.'
concepts.execution.ownership.description: 'A propriedade define quem libera um objeto; a conclusão do trabalho na GPU determina quando isso pode ocorrer. Chamar {dispose} libera os recursos nativos mesmo que ainda existam referências C# ao objeto. Enviar comandos não transfere à fila a propriedade dos recursos utilizados.'
concepts.execution.ownership.details: 'Ao encerrar a aplicação, pare de enviar trabalho e espere o último uso dos recursos em cada fila envolvida. Depois, libere os recursos da aplicação e o contexto. O contexto libera suas filas e estruturas auxiliares internas, portanto essa última etapa deve ocorrer após a conclusão de todo o trabalho da aplicação.'
-concepts.execution.ownership.guidance: 'Durante a renderização, acompanhe a conclusão do trabalho que utiliza dados a serem sobrescritos ou recursos a serem substituídos. Espere esses usos terminarem antes de modificar ou liberar o armazenamento afetado. {link} explica como esse modelo de tempo de vida se aplica às visualizações e aos recursos que as sustentam.'
+concepts.execution.ownership.guidance: 'Durante a renderização, acompanhe a conclusão do trabalho que utiliza dados a serem sobrescritos ou recursos a serem substituídos. Espere esses usos terminarem antes de modificar ou liberar o armazenamento afetado. O artigo {link} explica como esse modelo de tempo de vida se aplica às visualizações e aos recursos que as sustentam.'
concepts.execution.ownership.guidance.link: 'Gerenciamento de recursos'
concepts.execution.ownership.table.applicationResources.object: 'Recursos criados pela aplicação'
concepts.execution.ownership.table.applicationResources.ownership: 'A aplicação os libera após o último uso na GPU.'
@@ -18,7 +18,7 @@ concepts.execution.ownership.table.headings.ownership: 'Responsabilidade pela li
concepts.execution.ownership.table.queues.object: 'Filas do contexto e suas linhas do tempo'
concepts.execution.ownership.table.queues.ownership: 'O contexto e as filas as gerenciam.'
concepts.execution.ownership.table.swapChainDrawable.ownership: 'A cadeia de troca o gerencia.'
-concepts.execution.ownership.title: 'Responsabilidade e tempo de vida'
+concepts.execution.ownership.title: 'Propriedade e tempo de vida'
concepts.execution.pipelines.description: 'Um pipeline gráfico define os shaders, a disposição dos atributos de vértice, a montagem de primitivas, os formatos dos anexos e o estado usado nas operações de desenho. Selecione o pipeline antes de vincular dados de vértices, índices ou constantes. Os formatos dos anexos e a quantidade de amostras devem corresponder aos da passagem de renderização.'
concepts.execution.pipelines.details: 'Um pipeline de computação seleciona o ponto de entrada do shader executado por um despacho. Vincule o pipeline e suas constantes antes do despacho, fora de uma passagem de renderização gráfica.'
concepts.execution.pipelines.guidance: 'O {link} apresenta a sequência gráfica. O {detail} acrescenta um despacho de computação antes da passagem que exibe seu resultado.'
@@ -26,8 +26,8 @@ concepts.execution.pipelines.guidance.detail: 'exemplo de computação'
concepts.execution.pipelines.guidance.link: 'callback de renderização do triângulo'
concepts.execution.pipelines.title: 'Estado do pipeline'
concepts.execution.queues.description: 'A {graphicsQueue} costuma ser o ponto de partida para um quadro com desenho, computação e cópias. Manter operações dependentes na mesma fila simplifica a ordenação.'
-concepts.execution.queues.details: 'Filas distintas permitem enviar cargas de trabalho independentes separadamente, mas nem sempre correspondem a mecanismos de hardware independentes. Use filas adicionais quando houver benefício em sobrepor a execução. Se uma fila utilizar dados produzidos por outra, estabeleça uma dependência explícita entre seus envios.'
-concepts.execution.queues.guidance: 'Dentro de uma fila, operações dependentes também podem precisar de barreiras ou transições de textura para que os acessos posteriores vejam as escritas anteriores. Essas dependências de memória são diferentes da ordem de envio; {link} explica como expressá-las.'
+concepts.execution.queues.details: 'Filas adicionais podem ajudar a sobrepor cargas de trabalho independentes, embora nem sempre correspondam a unidades de hardware distintas. Se uma fila usar dados produzidos por outra, estabeleça uma dependência explícita entre os envios.'
+concepts.execution.queues.guidance: 'Dentro de uma fila, operações dependentes também podem precisar de barreiras ou transições de textura para que os acessos posteriores vejam as escritas anteriores. Essas dependências de memória são diferentes da ordem de envio; o artigo {link} explica como expressá-las.'
concepts.execution.queues.guidance.link: 'Sincronização'
concepts.execution.queues.table.computeQueue.workToRecord: 'Despachos de computação e trabalho de transferência compatível, sem passagens de renderização gráfica.'
concepts.execution.queues.table.graphicsQueue.workToRecord: 'Passagens de renderização, desenho, computação e transferências.'
@@ -35,33 +35,31 @@ concepts.execution.queues.table.headings.queue: 'Fila'
concepts.execution.queues.table.headings.workToRecord: 'Operações aceitas'
concepts.execution.queues.table.transferQueue.workToRecord: 'Uploads, downloads e cópias, sem desenho ou despachos de computação.'
concepts.execution.queues.title: 'Seleção de filas'
-concepts.execution.recording.context: 'A fila recupera os buffers de comandos concluídos para reutilizá-los. Obtenha um com {queueCommandBuffer} para cada registro de comandos, use uma thread por vez e envie-o uma única vez. Após o envio, deixe seu gerenciamento com a fila: não o modifique, envie novamente ou libere.'
-concepts.execution.recording.description: '{queueCommandBuffer} retorna um {commandBuffer} já em gravação. Registre as operações e suas dependências e chame {submit} uma vez. O envio encerra a gravação e retorna um {timelineValue}, que identifica o ponto de conclusão naquela fila.'
-concepts.execution.recording.details: 'Após registrar o quadro em {commandBuffer}, o tutorial do triângulo envia os comandos e aguarda a conclusão:'
-concepts.execution.recording.guidance: 'O registro monta a sequência de comandos; {submit} agenda sua execução. A chamada seguinte a {wait} bloqueia a thread da CPU até esse envio terminar. Isso facilita a compreensão do loop do tutorial, pois cada quadro termina antes do início do próximo.'
+concepts.execution.recording.context: 'A fila recupera os buffers de comandos concluídos para reutilizá-los. Obtenha um com {queueCommandBuffer} para cada gravação, grave os comandos em uma thread por vez e envie o buffer uma única vez. Após o envio, deixe-o sob responsabilidade da fila: não o modifique, não o reenvie nem o libere.'
+concepts.execution.recording.description: '{queueCommandBuffer} retorna um {commandBuffer} cuja gravação já começou. Grave as operações e suas dependências e chame {submit} uma vez. O envio encerra a gravação e retorna um {timelineValue}, que identifica o ponto de conclusão naquela fila.'
+concepts.execution.recording.details: 'Após gravar os comandos do quadro em {commandBuffer}, o tutorial do triângulo os envia e aguarda a conclusão:'
+concepts.execution.recording.guidance: 'A gravação define a sequência de comandos; {submit} agenda sua execução. A chamada seguinte a {wait} bloqueia a thread da CPU até esse envio terminar. Isso facilita a compreensão do loop do tutorial, pois cada quadro termina antes do início do próximo.'
concepts.execution.recording.title: 'Gravação e envio'
concepts.execution.title: 'Modelo de execução'
-concepts.platforms.description: 'A apresentação pode ser gerenciada pela aplicação ou por um controle de interface. Essa escolha define quem obtém a textura de saída do quadro, registra e envia os comandos e apresenta o resultado. Essa textura de saída é o drawable.'
-concepts.platforms.frame.context: 'Registre as vinculações de pipeline e os comandos de desenho dentro da passagem e encerre-a antes de o manipulador retornar. O controle envia os comandos e apresenta o resultado. O manipulador não deve enviar o buffer de comandos nem liberar qualquer um dos objetos recebidos. Se alterar o layout da textura de saída, restaure {colorAttachment} antes de retornar para que o controle realize a transição final.'
-concepts.platforms.frame.description: 'Os controles implementam {iZenithView}. A aplicação atribui {graphicsContext}, atualiza a cena em {updateRequested} e registra comandos em {renderRequested} usando o {renderEventArgs} recebido.'
-concepts.platforms.frame.details: 'A cada quadro, o controle obtém uma textura de saída e um buffer de comandos, faz a transição da textura para {colorAttachment} e chama os manipuladores de atualização e renderização. Depois, envia o trabalho registrado e apresenta a imagem pelo mecanismo do framework.'
+concepts.platforms.description: 'A apresentação pode ser gerenciada pela aplicação ou por um controle de interface. Essa escolha define quem obtém a textura de saída do quadro, grava e envia os comandos e apresenta o resultado. Essa textura de saída é o drawable.'
+concepts.platforms.frame.context: 'Grave os comandos de vinculação de pipeline e de desenho dentro da passagem e encerre-a antes de o manipulador retornar. O manipulador não deve enviar o buffer de comandos nem liberar qualquer um dos objetos recebidos. Se alterar o layout da textura de saída, restaure {colorAttachment} antes de retornar para que o controle realize a transição final.'
+concepts.platforms.frame.description: 'Os controles implementam {iZenithView}. A aplicação atribui {graphicsContext}, atualiza a cena em {updateRequested} e grava comandos em {renderRequested} usando o {renderEventArgs} recebido.'
+concepts.platforms.frame.details: 'A cada quadro, o controle obtém uma textura de saída e um buffer de comandos, faz a transição da textura para {colorAttachment} e chama os manipuladores de atualização e renderização. Depois, envia os comandos gravados e apresenta a imagem pelo mecanismo do framework.'
concepts.platforms.frame.guidance: 'Adicione {usingZenithNET} ao arquivo. Para uma instância de {iZenithView} chamada {view}, já inicializada e com um contexto gráfico atribuído, registre este manipulador para limpar sua textura de saída:'
concepts.platforms.frame.notes: 'A transição inicial usa {undefined}, que permite descartar o conteúdo anterior da imagem. Desenhe ou limpe a imagem inteira a cada quadro. Mantenha resultados acumulados ou em cache em uma textura da aplicação e depois a desenhe na textura de saída do controle.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} fornece o formato de cor padrão dessas integrações.'
concepts.platforms.frame.title: 'Renderização em controles de interface'
-concepts.platforms.integration.context: 'WinForms, WPF e a integração Windows do WinUI executam no Windows. Para MAUI, instale a carga de trabalho da plataforma de destino e registre o manipulador do controle com {useZenithView}, como mostra {extensionsCs}.'
+concepts.platforms.integration.context: 'WinForms, WPF e a integração com WinUI descrita aqui funcionam no Windows. Para MAUI, instale a carga de trabalho da plataforma de destino e registre o manipulador do controle com {useZenithView}, como mostra {extensionsCs}.'
concepts.platforms.integration.description: 'A interface de eventos é comum, mas o mecanismo de apresentação depende do framework:'
-concepts.platforms.integration.details: 'Essas implementações diferem na forma de levar a imagem da GPU à interface. A leitura como bitmap copia os pixels para a memória da CPU antes da exibição. A interoperabilidade por texturas compartilhadas evita essa cópia, mas ainda pode exigir cópias na GPU e sincronização. Ao escolher uma integração, considere esse caminho de apresentação além do evento comum {renderRequested}.'
-concepts.platforms.integration.guidance: 'Adicione pelo NuGet o pacote de integração correspondente ao seu framework de interface. Para Avalonia, use {avaloniaPackage}.'
+concepts.platforms.integration.details: 'As integrações apresentam as imagens da GPU de maneiras diferentes. Na apresentação por bitmap, os pixels são copiados para a memória da CPU antes da exibição. A interoperabilidade por texturas compartilhadas evita essa cópia, mas ainda pode exigir cópias na GPU e sincronização. Ao escolher uma integração, considere o caminho de apresentação junto com o evento comum {renderRequested}.'
concepts.platforms.integration.table.avalonia.integration: 'Avalonia'
-concepts.platforms.integration.table.avalonia.presentation: 'Renderiza em uma textura e copia os pixels para a memória da CPU em {writeableBitmap}. Implementação: {zenithViewCs} e {surfaceCs}.'
+concepts.platforms.integration.table.avalonia.presentation: 'Renderiza em uma textura e copia os pixels para um {writeableBitmap} na memória da CPU. Consulte {zenithViewCs} e {surfaceCs}.'
concepts.platforms.integration.table.headings.integration: 'Integração'
concepts.platforms.integration.table.headings.presentation: 'Mecanismo de apresentação'
concepts.platforms.integration.table.maui.integration: '.NET MAUI'
concepts.platforms.integration.table.maui.presentation: 'Usa superfícies nativas no Android, iOS e Mac Catalyst, e composição de textura compartilhada no Windows. Consulte as {link}.'
concepts.platforms.integration.table.maui.presentation.link: 'implementações de plataforma'
-concepts.platforms.integration.table.uno.integration: 'Caminho Uno'
-concepts.platforms.integration.table.uno.presentation: 'Copia os pixels para a memória da CPU em {writeableBitmap}. Implementação: {zenithViewUnoCs}.'
+concepts.platforms.integration.table.uno.integration: 'Uno Platform'
+concepts.platforms.integration.table.uno.presentation: 'Copia os pixels para um {writeableBitmap} na memória da CPU. Consulte {zenithViewUnoCs}.'
concepts.platforms.integration.table.winForms.integration: 'WinForms'
concepts.platforms.integration.table.winForms.presentation: 'Cria uma cadeia de troca do Zenith.NET para o {hWND} do controle. Consulte {zenithViewCs}.'
concepts.platforms.integration.table.winUI.integration: 'WinUI no Windows'
@@ -69,23 +67,23 @@ concepts.platforms.integration.table.winUI.presentation: 'Renderiza em uma textu
concepts.platforms.integration.table.wpf.integration: 'WPF'
concepts.platforms.integration.table.wpf.presentation: 'Importa uma textura Direct3D 11 compartilhada e copia seu conteúdo, por meio da interoperabilidade com Direct3D, para uma superfície exibida por {d3DImage}. Consulte {surfaceCs}.'
concepts.platforms.integration.title: 'Framework e apresentação'
-concepts.platforms.lifecycle.context: 'Ao criar anexos compatíveis, use {descWidth}, {descHeight}, {descFormat} e {descSampleCount} da textura de saída fornecida pelo evento de renderização. Essa textura informa as dimensões reais do destino; elas não devem ser deduzidas do tamanho de layout do controle nem da escala de exibição.'
+concepts.platforms.lifecycle.context: 'Ao criar anexos compatíveis, use {descWidth}, {descHeight}, {descFormat} e {descSampleCount} da textura de saída fornecida pelo evento de renderização. Essa textura informa as dimensões reais do destino; não as deduza das dimensões do controle no layout nem da escala de exibição.'
concepts.platforms.lifecycle.description: 'A cadeia de troca usa a largura e a altura do framebuffer em pixels, que podem diferir das dimensões lógicas da janela quando há escala de exibição. Adie a renderização e o redimensionamento da cadeia enquanto alguma dimensão for zero. Obtenha {swapChainDrawable} a cada quadro: a textura pertence à cadeia de troca, que pode substituí-la após apresentar ou redimensionar.'
concepts.platforms.lifecycle.details: 'Quando o tamanho do framebuffer mudar, espere os usos pendentes das imagens antigas na GPU antes de chamar {swapChainResize}. Para substituir o destino nativo de apresentação, aguarde esses usos da mesma forma e passe a nova descrição da superfície e seus identificadores a {swapChainRefresh}. No encerramento, libere a cadeia de troca antes de destruir seu destino nativo.'
concepts.platforms.lifecycle.guidance: 'Se a aplicação tiver texturas de profundidade ou fora da tela que acompanham o tamanho da janela, recrie-as quando esse tamanho mudar e atualize as constantes que contêm seus identificadores. O pipeline pode ser reutilizado enquanto os formatos e as quantidades de amostras dos anexos continuarem correspondentes. O {link} mostra essa separação entre as texturas redimensionadas e o pipeline reutilizável.'
concepts.platforms.lifecycle.guidance.link: 'renderizador de cubo giratório'
concepts.platforms.lifecycle.title: 'Dimensões e tempo de vida da cadeia de troca'
concepts.platforms.ownership.description: 'O contexto atribuído e os recursos de renderização pertencem à aplicação; os recursos de apresentação pertencem ao controle. Quando {graphicsContext} muda na visualização, o agendador recria os recursos do controle para o novo contexto. Recrie também os pipelines, buffers e texturas da aplicação para esse contexto.'
-concepts.platforms.ownership.details: 'Antes de substituir recursos de renderização, interrompa o processamento de quadros da visualização e espere o trabalho da GPU que os utiliza. Só então libere os recursos ou o contexto antigos. Ao remover a visualização, a aplicação continua responsável por liberar o contexto atribuído a ela.'
-concepts.platforms.ownership.guidance: 'O componente compartilhado {frameSchedulerCs} executa os manipuladores de quadro pelo dispatcher da interface. Concentre esses manipuladores na atualização da cena e no registro de comandos: um processamento prolongado na CPU também atrasa a resposta da interface.'
+concepts.platforms.ownership.details: 'Antes de substituir recursos de renderização, interrompa o loop de quadros da visualização e espere o trabalho da GPU que os utiliza terminar. Depois, libere os recursos antigos. Libere o contexto somente depois que todas as visualizações tiverem liberado seus recursos de apresentação associados a esse contexto e todos os recursos da aplicação criados a partir dele tiverem sido liberados.'
+concepts.platforms.ownership.guidance: 'O componente compartilhado {frameSchedulerCs} executa os manipuladores de quadro pelo dispatcher da interface. Concentre esses manipuladores na atualização da cena e na gravação de comandos: um processamento prolongado na CPU também atrasa a resposta da interface.'
concepts.platforms.ownership.title: 'Responsabilidades da aplicação e do controle'
concepts.platforms.surface.description: 'O {link} usa Silk.NET para criar a janela e processar seus eventos. O Zenith.NET recebe os identificadores nativos e as dimensões em uma descrição {surface}, usada para criar uma {swapChain}. A aplicação continua responsável pela janela do sistema operacional.'
concepts.platforms.surface.description.link: 'tutorial do triângulo'
-concepts.platforms.surface.details: 'Os identificadores da superfície devem corresponder ao backend:'
+concepts.platforms.surface.details: 'Os identificadores da superfície dependem da API gráfica e do sistema de janelas. Combinações comuns são:'
concepts.platforms.surface.guidance: 'O programa hospedeiro em {appCs} oferece suporte a Windows, macOS e X11. Sua janela Linux fornece identificadores Xlib, portanto uma sessão Wayland precisa de XWayland para executá-lo. Uma aplicação nativa de Wayland fornece os identificadores de display e superfície por meio de {surfaceWayland}.'
concepts.platforms.surface.table.android.backend: 'Vulkan no Android.'
concepts.platforms.surface.table.apple.backend: 'Metal nas plataformas Apple.'
-concepts.platforms.surface.table.headings.backend: 'Backend e plataforma'
+concepts.platforms.surface.table.headings.backend: 'API gráfica e plataforma'
concepts.platforms.surface.table.headings.factory: 'Fábrica de superfícies'
concepts.platforms.surface.table.headings.handles: 'Identificadores fornecidos pelo programa hospedeiro'
concepts.platforms.surface.table.wayland.backend: 'Vulkan com um host nativo Wayland.'
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'Superfícies nativas de apresentação'
concepts.platforms.title: 'Integração de plataforma'
concepts.resources.allocation.context: 'Os recursos colocados em um heap dependem de seu armazenamento durante todo o tempo de vida. Depois do último uso na GPU, libere os recursos antes de liberar o heap.'
concepts.resources.allocation.description: 'Use um {heap} quando a aplicação precisar gerenciar as alocações por conta própria. Um heap fornece armazenamento no qual os recursos são colocados em deslocamentos explícitos em bytes; a aplicação escolhe esses deslocamentos e acompanha as regiões ocupadas.'
-concepts.resources.allocation.details: 'Para cada recurso, chame {contextGetSizeAndAlignment} com a descrição de buffer ou textura que será usada na criação. Reserve o tamanho retornado em um deslocamento múltiplo do alinhamento informado, dentro dos limites do heap e sem sobrepor outra alocação ainda em uso. Texturas podem incluir preenchimento específico do backend; por isso, a quantidade de pixels e os bytes por pixel não bastam para calcular o tamanho da alocação.'
+concepts.resources.allocation.details: 'Para cada recurso, chame {contextGetSizeAndAlignment} com a descrição de buffer ou textura que será usada na criação. Reserve o tamanho retornado em um deslocamento múltiplo do alinhamento informado, dentro dos limites do heap e sem sobrepor outra alocação ainda em uso. A alocação de uma textura pode incluir preenchimento; por isso, a quantidade de pixels e os bytes por pixel não bastam para calcular seu tamanho.'
concepts.resources.allocation.guidance: 'Um buffer colocado em um heap deve declarar a mesma residência desse heap. Para armazenar texturas, use um heap exclusivo da GPU.'
concepts.resources.allocation.title: 'Alocação em heaps'
concepts.resources.bufferUsages.table.constant.role: 'Parâmetros de shader lidos por meio de uma vinculação de buffer de constantes.'
@@ -115,7 +113,7 @@ concepts.resources.bufferUsages.title: 'Usos de buffer'
concepts.resources.description: 'A descrição de um recurso define como a aplicação pode usar seu armazenamento. Por exemplo, uma textura usada como destino de renderização, amostrada por um shader e copiada de volta à CPU precisa dos indicadores de uso das três operações. A localização da memória determina o acesso da CPU; a sincronização e o gerenciamento do tempo de vida determinam quando os dados podem ser acessados ou o armazenamento liberado.'
concepts.resources.memory.context: 'Nos buffers acessíveis pela CPU, {map} fornece o endereço pelo qual os dados são lidos ou escritos. Nem o mapeamento nem {unmap} esperam o trabalho da GPU: antes de ler um resultado, a aplicação precisa esperar a escrita que o produz; antes de modificar os mesmos bytes, precisa esperar os acessos pendentes da GPU.'
concepts.resources.memory.description: 'O campo {residency} de {bufferDesc} especifica o acesso pretendido pela CPU:'
-concepts.resources.memory.details: 'A residência expressa os requisitos de acesso da CPU, inclusive em sistemas em que CPU e GPU compartilham memória física. O triângulo utiliza {cpuWriteOnly} para inicializar diretamente seu pequeno buffer de vértices. Para geometrias estáticas maiores, pode ser mais adequado enviar os dados para armazenamento exclusivo da GPU.'
+concepts.resources.memory.details: 'A residência expressa os requisitos de acesso da CPU, inclusive em sistemas em que CPU e GPU compartilham memória física. O triângulo utiliza {cpuWriteOnly} para inicializar diretamente seu pequeno buffer de vértices. Para geometrias estáticas maiores, pode ser mais adequado fazer upload dos dados para armazenamento exclusivo da GPU.'
concepts.resources.memory.guidance: 'Texturas criadas diretamente pelo contexto usam armazenamento da GPU. Por isso, {textureDesc} não possui um campo de residência; a aplicação troca seus dados com a memória da CPU por meio de uploads e downloads.'
concepts.resources.memory.table.cpuReadOnly.cPUAccess: 'Somente leitura'
concepts.resources.memory.table.cpuReadOnly.typicalRole: 'Dados produzidos pela GPU para leitura na CPU'
@@ -128,7 +126,7 @@ concepts.resources.memory.table.headings.residency: 'Residência'
concepts.resources.memory.table.headings.typicalRole: 'Função típica'
concepts.resources.memory.title: 'Acesso pela CPU e localização na memória'
concepts.resources.textureUsages.description: 'Os indicadores de transferência descrevem se o recurso é a origem ou o destino de uma cópia na GPU. A possibilidade de acesso direto pela CPU é uma decisão separada, tomada ao escolher a localização da memória.'
-concepts.resources.textureUsages.details: 'Os indicadores de uso declaram as funções que uma textura pode desempenhar. Alternar entre elas exige os cuidados de {link} correspondentes, e o dispositivo escolhido deve oferecer suporte a esses usos para o formato da textura.'
+concepts.resources.textureUsages.details: 'Os indicadores de uso declaram as funções que uma textura pode desempenhar. Ao alternar entre elas, aplique as regras correspondentes de {link}; o dispositivo escolhido também deve oferecer suporte a esses usos para o formato da textura.'
concepts.resources.textureUsages.details.link: 'layout e sincronização'
concepts.resources.textureUsages.table.colorAttachment.role: 'Um anexo de cor em uma passagem de renderização.'
concepts.resources.textureUsages.table.depthStencilAttachment.role: 'Um anexo de profundidade e estêncil em uma passagem de renderização.'
@@ -144,29 +142,29 @@ concepts.resources.title: 'Gerenciamento de recursos'
concepts.resources.transfers.context: 'Um download copia primeiro os dados da GPU para uma área interna de leitura. A biblioteca os copia para o destino de CPU fornecido quando recupera o buffer de comandos concluído. Chamar {wait} no valor de envio do download completa as duas etapas. Mantenha o destino alocado e a memória gerenciada fixada até o retorno dessa chamada.'
concepts.resources.transfers.description: 'Uploads copiam dados da CPU para um recurso da GPU; downloads copiam dados do recurso para a memória da CPU. Os métodos de buffers e texturas concluem essa transferência antes de retornar:'
concepts.resources.transfers.details: 'Antes de chamar esses métodos, resolva os acessos conflitantes em outras filas. A espera interna do método abrange sua própria transferência; ela não estabelece uma dependência de outra fila. Nas cópias diretas por memória mapeada, cabe inteiramente a quem chama esperar os acessos conflitantes da GPU.'
-concepts.resources.transfers.guidance: 'Para enviar transferências junto com outro trabalho da GPU, registre-as com {commandBufferUpload} ou {commandBufferDownload}. A memória de origem de um upload e a de destino de um download precisam permanecer válidas por períodos diferentes:'
+concepts.resources.transfers.guidance: 'Para incluir transferências no mesmo envio que outras operações da GPU, grave-as com {commandBufferUpload} ou {commandBufferDownload}. A memória de origem de um upload e a de destino de um download precisam permanecer válidas por períodos diferentes:'
concepts.resources.transfers.item: 'Durante uma chamada de upload, a biblioteca copia os dados de origem para uma área temporária de transferência. A GPU lê dessa área posteriormente, portanto o ponteiro de origem da aplicação só é necessário até o retorno da chamada.'
-concepts.resources.transfers.notes: 'Nas transferências de textura, o passo de linha é a distância em bytes entre linhas consecutivas dos dados da CPU; o passo de fatia é a distância entre fatias de profundidade consecutivas. Esses valores permitem copiar os dados entre sua organização na CPU e o armazenamento da textura na GPU. {link} explica por que concluir a cópia na GPU e entregar os dados ao destino de um download são etapas distintas.'
-concepts.resources.transfers.notes.link: 'Sincronização'
+concepts.resources.transfers.layouts: 'As transferências de textura gravadas no buffer de comandos não incluem transições de layout. Uploads exigem {copyDst}, e downloads exigem {copySrc}. Grave as transições para esses layouts antes da cópia e, depois dela, para o layout exigido pelo próximo uso.'
+concepts.resources.transfers.notes: 'Nas transferências de textura, o passo de linha é a distância em bytes entre linhas consecutivas dos dados da CPU; o passo de fatia é a distância entre fatias de profundidade consecutivas. Esses valores orientam a cópia entre os dados da CPU e o armazenamento da textura na GPU.'
concepts.resources.transfers.table.bufferDownload.transfer: 'Para {cpuReadOnly}, copia diretamente da memória mapeada. Nos demais casos, envia o download à fila de transferência e espera sua conclusão.'
concepts.resources.transfers.table.bufferUpload.transfer: 'Para {cpuWriteOnly}, copia diretamente para a memória mapeada. Nos demais casos, envia o upload à fila de transferência e espera sua conclusão.'
concepts.resources.transfers.table.headings.method: 'Método'
concepts.resources.transfers.table.headings.transfer: 'Comportamento da transferência'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'Envia a cópia e as transições de textura à fila gráfica e espera sua conclusão. O sub-recurso selecionado fica no layout final solicitado.'
-concepts.resources.transfers.title: 'Transferências imediatas e registradas'
+concepts.resources.transfers.title: 'Transferências imediatas e por buffer de comandos'
concepts.resources.usages.description: '{bufferUsages} e {textureUsages} são enumerações de indicadores que declaram os usos de um recurso. Seus valores são atribuídos a {bufferDescUsages} e {textureDescUsages}, respectivamente. Para vários usos, combine os membros necessários com {value}.'
concepts.resources.usages.title: 'Usos de recursos'
-concepts.resources.views.description: 'Uma {bufferView} descreve uma região de um buffer e a interpretação de seus dados. Uma {textureView} seleciona um intervalo de sub-recursos, com um tipo e formato de textura compatíveis. Ambas se referem ao armazenamento existente, com os usos declarados na criação. Os intervalos das visualizações descrevem o acesso, mas não garantem uma verificação de limites uniforme nos shaders de todos os backends.'
+concepts.resources.views.description: 'Uma {bufferView} descreve uma região de um buffer e a interpretação de seus dados. Uma {textureView} seleciona um intervalo de sub-recursos, com um tipo e formato de textura compatíveis. Ambas se referem a um armazenamento já criado, cujos usos foram declarados na criação. Os intervalos das visualizações descrevem o acesso, mas não garantem uma verificação uniforme de limites nos shaders.'
concepts.resources.views.details: 'O identificador do próprio recurso fornece sua visualização padrão. Crie uma visualização separada para escolher outra região ou uma interpretação compatível diferente. Mantenha vivos tanto a visualização quanto o recurso que a sustenta até a GPU terminar de utilizá-los; um identificador não mantém nenhum desses objetos vivo. Ao substituir qualquer um deles, atualize as constantes que contêm o {link} anterior.'
concepts.resources.views.details.link: 'identificador de recurso'
concepts.resources.views.title: 'Visualizações e recursos subjacentes'
concepts.shaders.binding.context: 'O exemplo de computação atribui {inputTextureSampledHandle} a {input} e {outputTextureStorageHandle} a {output}. Em Slang, o parâmetro de tipo de {descriptorHandle} define como o shader acessa cada recurso:'
-concepts.shaders.binding.description: '{setConstantBuffer} seleciona um buffer existente e o deslocamento de byte a partir do qual o pipeline atual lê suas constantes. Envie os parâmetros para esse armazenamento antes de serem usados pelo shader. Se um trabalho anterior da GPU ainda estiver lendo os mesmos bytes, espere sua conclusão antes de atualizá-los.'
-concepts.shaders.binding.details: 'Com o buffer de comandos, o pipeline de computação, o buffer de constantes preenchido e as quantidades de grupos de threads prontos, registre o despacho nesta ordem. Selecione primeiro o pipeline, pois a vinculação do buffer de constantes se aplica a ele:'
-concepts.shaders.binding.guidance: 'Aqui, {commandBuffer} registra um despacho com {computePipeline} e os parâmetros armazenados em {constantBuffer}. O buffer precisa do uso {bufferUsagesConstant}, e o deslocamento 0 seleciona seu início. Se vários registros de constantes compartilharem um buffer, o deslocamento inicial de cada registro também deve atender ao alinhamento de vinculação do backend, independentemente do layout de seus campos internos.'
-concepts.shaders.binding.notes: '{resourceHandle} contém dois campos de 32 bits cuja interpretação depende do backend. Seus valores são válidos apenas no contexto em que o recurso foi criado.'
-concepts.shaders.binding.reference: 'Mantenha o recurso e a visualização usada para obter seu identificador até o último acesso do shader. A substituição exige atualizar constantes que ainda contenham o identificador antigo. {link} apresenta as regras de responsabilidade.'
+concepts.shaders.binding.description: '{setConstantBuffer} seleciona um buffer existente e o deslocamento de byte a partir do qual o pipeline atual lê suas constantes. Faça o upload dos parâmetros para esse armazenamento antes de serem usados pelo shader. Se um trabalho anterior da GPU ainda estiver lendo os mesmos bytes, espere sua conclusão antes de atualizá-los.'
+concepts.shaders.binding.details: 'Com o buffer de comandos, o pipeline de computação, o buffer de constantes preenchido e as quantidades de grupos de threads prontos, grave o despacho nesta ordem. Selecione primeiro o pipeline, pois a vinculação do buffer de constantes se aplica a ele:'
+concepts.shaders.binding.guidance: 'O buffer de constantes precisa do uso {bufferUsagesConstant}. Se vários registros de constantes compartilharem um buffer, o deslocamento inicial de cada registro deve atender ao alinhamento exigido para a vinculação. Essa exigência é independente do layout dos campos internos de cada registro.'
+concepts.shaders.binding.notes: '{resourceHandle} contém dois campos de 32 bits cuja interpretação depende da implementação da API gráfica. Seus valores são válidos apenas no contexto em que o recurso foi criado.'
+concepts.shaders.binding.reference: 'Mantenha o recurso e a visualização usada para obter seu identificador até a conclusão do último acesso do shader. Ao substituir uma textura ou visualização, atualize as constantes que ainda contenham o identificador antigo. O artigo {link} apresenta as regras de propriedade e tempo de vida.'
concepts.shaders.binding.reference.link: 'Gerenciamento de recursos'
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'Leitura de elementos estruturados do tipo {t} do shader'
concepts.shaders.binding.table.bufferStorageReadWriteHandle.access: 'Leitura e escrita de elementos estruturados do tipo {t} do shader'
@@ -177,9 +175,9 @@ concepts.shaders.binding.table.samplerHandle.access: 'Estado de amostragem de te
concepts.shaders.binding.table.textureSampledHandle.access: 'Leitura de texturas'
concepts.shaders.binding.table.textureStorageHandle.access: 'Leitura e escrita de texturas de armazenamento'
concepts.shaders.binding.title: 'Buffers de constantes e identificadores de recursos'
-concepts.shaders.compilation.description: '{zenithCompiler} compila um ponto de entrada Slang em uma {shaderDesc}. O {graphicsApi} do contexto define o destino: DXIL para DirectX 12, biblioteca Metal para Metal ou SPIR-V para Vulkan.'
+concepts.shaders.compilation.description: '{zenithCompiler} compila um ponto de entrada Slang e retorna um {shaderDesc}. O {graphicsApi} do contexto seleciona o formato de saída: {dxil} para DirectX 12, {metallib} para Metal ou {spirv} para Vulkan.'
concepts.shaders.compilation.details: 'Com um contexto gráfico já criado e chamado {context}, compile o shader do triângulo a partir da cópia ao lado do executável:'
-concepts.shaders.compilation.guidance: 'O nome do ponto de entrada {vSMain} deve corresponder à declaração no arquivo de shader. Compile os shaders e crie os pipelines na inicialização; depois, reutilize os pipelines durante a renderização. Após a criação dos pipelines, os objetos shader podem ser liberados, como mostra {link}.'
+concepts.shaders.compilation.guidance: 'O nome do ponto de entrada {vSMain} deve corresponder à declaração no arquivo de shader. Compile os shaders e crie os pipelines na inicialização; depois, reutilize os pipelines durante a renderização. Após a criação dos pipelines, os objetos de shader podem ser liberados, como mostra {link}.'
concepts.shaders.compilation.guidance.link: 'Primeiro triângulo'
concepts.shaders.compilation.title: 'Compilação de shaders'
concepts.shaders.description: 'As declarações em C# e Slang precisam concordar quanto à posição de cada valor e ao acesso feito pelo shader. Layouts de entrada descrevem os atributos dos vértices; declarações de buffers do shader descrevem parâmetros e arrays; identificadores apontam para os recursos usados pelo shader.'
@@ -189,11 +187,11 @@ concepts.shaders.dispatch.details.link: 'Sincronização'
concepts.shaders.dispatch.title: 'Grupos de threads'
concepts.shaders.layout.context: 'As {link} ilustram essa organização com as dimensões de uma imagem e dois identificadores de textura. Deslocamentos explícitos indicam onde cada campo começa. A declaração usa {systemRuntimeInteropServices} e {zenithNET}:'
concepts.shaders.layout.context.link: 'constantes C# do exemplo de computação'
-concepts.shaders.layout.description: 'Para a entrada de vértices, {inputLayout} descreve o formato, o deslocamento e a semântica de cada atributo, além do passo entre vértices. O triângulo coloca uma posição {float3} antes de uma cor {float4}: a cor começa no deslocamento de byte 12 e cada vértice ocupa 28 bytes. {inputLayoutAdd} calcula essa organização compacta a partir dos formatos. Se a estrutura C# contiver preenchimento, informe deslocamentos e um passo que o considerem.'
+concepts.shaders.layout.description: 'Para a entrada de vértices, {inputLayout} descreve o formato, o deslocamento e a semântica de cada atributo, além do passo entre vértices. O triângulo coloca uma posição {float3} antes de uma cor {float4}: a cor começa no deslocamento de byte 12 e cada vértice ocupa 28 bytes. {inputLayoutAdd} calcula essa organização compacta a partir dos formatos. Se a estrutura C# contiver preenchimento, ajuste os deslocamentos e o passo para incluí-lo.'
concepts.shaders.layout.details: 'Buffers de constantes contêm parâmetros do shader, e buffers estruturados contêm arrays de elementos tipados. Seus layouts seguem as declarações de Slang, e não {inputLayout}. Ajuste os deslocamentos dos campos, tamanhos dos elementos e preenchimento em C# ao layout do shader compilado. Um tipo não gerenciado de C# pode ser copiado byte a byte, mas seu layout na memória não corresponde necessariamente ao do shader; um {float3} armazenado sem preenchimento em um vértice pode exigir outro alinhamento em um buffer do shader.'
concepts.shaders.layout.guidance: 'Os parâmetros do shader podem incluir identificadores de recursos além de valores comuns. Um identificador aponta para armazenamento já existente, portanto copiá-lo para um buffer de constantes não copia o conteúdo do recurso.'
concepts.shaders.layout.notes: 'A declaração correspondente em {computeShaderSlang} é:'
-concepts.shaders.layout.reference: 'As duas dimensões ocupam os primeiros oito bytes, seguidas de dois identificadores de oito bytes cada. O exemplo C# reserva 256 bytes para o registro completo. Para outros registros, determine o tamanho a partir de seus próprios campos e requisitos de layout e alinhamento.'
+concepts.shaders.layout.reference: 'Os campos C# ocupam os primeiros 24 bytes: oito para as dimensões e oito para cada identificador. O registro de 256 bytes deixa os bytes restantes como preenchimento. Para outro bloco de parâmetros, ajuste os deslocamentos dos campos ao layout de seu shader. Se vários registros compartilharem um buffer, inclua preenchimento suficiente entre eles para atender ao alinhamento exigido para a vinculação.'
concepts.shaders.layout.title: 'Layout de dados'
concepts.shaders.matrices.description: 'O compilador usa armazenamento de matrizes por linhas, mantendo cada linha contígua. O {link} armazena três valores {matrix4x4} nos deslocamentos 0, 64 e 128. Seu {detail} aplica {mulVectorMatrix} na ordem modelo, visão e projeção.'
concepts.shaders.matrices.description.detail: 'shader'
@@ -201,49 +199,49 @@ concepts.shaders.matrices.description.link: 'renderizador de cubo giratório'
concepts.shaders.matrices.details: 'A ordem de armazenamento determina a disposição dos elementos da matriz na memória; a ordem de multiplicação determina a transformação. C# e Slang devem adotar convenções compatíveis.'
concepts.shaders.matrices.title: 'Convenções de matrizes'
concepts.shaders.title: 'Dados de shaders e vinculação'
-concepts.synchronization.backends.description: 'DirectX 12 e Vulkan codificam as transições de textura como mudanças de layout e acesso. Em Metal, a implementação de {transition} do Zenith.NET não executa uma operação equivalente. O backend de Metal reúne os comandos em codificadores de renderização e computação e insere barreiras de visibilidade ao encerrar cada codificador. Operações dependentes no mesmo codificador, como despachos de computação sucessivos, usam chamadas explícitas a {barrier}.'
-concepts.synchronization.backends.details: 'No {link}, iniciar a passagem gráfica encerra o codificador de computação e torna sua saída visível ao trabalho gráfico. Dois despachos consecutivos permanecem no mesmo codificador, portanto sua dependência exige uma barreira mesmo que haja uma transição de textura entre eles. Por isso, uma sequência de comandos portável deve considerar as dependências de acesso além dos layouts de textura.'
+concepts.synchronization.backends.description: 'DirectX 12 e Vulkan codificam as transições de textura como mudanças de layout e acesso. Na implementação de Metal do Zenith.NET, {transition} não gera uma operação equivalente na GPU. Essa implementação reúne os comandos em codificadores de renderização e computação e insere barreiras de visibilidade ao encerrar cada codificador. Operações dependentes no mesmo codificador, como despachos de computação sucessivos, exigem chamadas explícitas a {barrier}.'
+concepts.synchronization.backends.details: 'No {link}, iniciar a passagem gráfica encerra o codificador de computação e torna sua saída visível ao trabalho gráfico. Dois despachos consecutivos permanecem no mesmo codificador, portanto sua dependência exige uma barreira mesmo que haja uma transição de textura entre eles.'
concepts.synchronization.backends.details.link: 'exemplo de computação'
-concepts.synchronization.backends.title: 'Comportamento dos backends'
+concepts.synchronization.backends.title: 'Sincronização conforme a API gráfica'
concepts.synchronization.barriers.context: 'Escolha etapas que incluam os acessos envolvidos e sejam compatíveis com a fila. {barrierStagesAll} inclui todas as etapas compatíveis; selecione um conjunto menor quando a dependência envolver apenas essas etapas.'
-concepts.synchronization.barriers.description: 'Considere dois despachos de computação registrados no mesmo buffer de comandos: o primeiro escreve dados de simulação e o segundo os lê. Coloque uma barreira entre eles para que o segundo veja as escritas concluídas. Em um buffer de armazenamento, isso ordena os acessos sem uma transição de layout de textura:'
+concepts.synchronization.barriers.description: 'Considere dois despachos de computação gravados no mesmo buffer de comandos: o primeiro escreve dados de simulação e o segundo os lê. Coloque uma barreira entre eles para que o segundo veja as escritas concluídas. Em um buffer de armazenamento, isso ordena os acessos sem uma transição de layout de textura:'
concepts.synchronization.barriers.details: 'O primeiro argumento identifica as etapas que produzem os dados; o segundo, as etapas que os consomem. Juntos, eles descrevem a ordem de execução e a visibilidade de memória necessárias entre os dois despachos.'
-concepts.synchronization.barriers.guidance: 'A {link} usa esse padrão entre etapas da simulação. Cada barreira fica depois do despacho que produz os dados e antes daquele que os utiliza.'
+concepts.synchronization.barriers.guidance: 'A {link} usa esse padrão entre etapas da simulação.'
concepts.synchronization.barriers.guidance.link: 'simulação FluidTank'
concepts.synchronization.barriers.title: 'Barreiras do pipeline'
concepts.synchronization.dependencies.description: 'Para cada recurso, identifique os acessos aos mesmos dados. Se algum deles escrever, preserve a ordem necessária entre as operações. Duas leituras não entram em conflito, embora os requisitos de layout de textura e apresentação continuem válidos. Atualizações pela CPU e a liberação de recursos também precisam esperar a GPU terminar de usar o armazenamento afetado.'
concepts.synchronization.dependencies.details: 'O mecanismo adequado depende de onde as operações são executadas:'
-concepts.synchronization.dependencies.guidance: 'Uma carga de trabalho pode precisar de mais de um mecanismo. Por exemplo, uma textura produzida em outra fila precisa de uma dependência entre envios e do layout adequado para o próximo uso. Nenhuma dessas operações exige bloquear a CPU, a menos que ela própria precise acessar ou liberar os dados.'
-concepts.synchronization.dependencies.table.cpuAccess.mechanism: 'Chamar {wait} no valor de conclusão relevante.'
+concepts.synchronization.dependencies.guidance: 'Quando uma fila escreve em uma textura usada por outra, inclua uma dependência no envio da fila consumidora e grave a transição de layout necessária. Nenhuma dessas etapas bloqueia a CPU. Espere a conclusão do trabalho na GPU antes de a CPU acessar os dados ou liberar o recurso.'
+concepts.synchronization.dependencies.table.cpuAccess.mechanism: 'Chame {wait} no valor de conclusão relevante.'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'O acesso da CPU ou a liberação de recursos depende da conclusão na GPU'
concepts.synchronization.dependencies.table.crossQueue.mechanism: 'Passe o {timelineValue} do produtor para o {submit} do consumidor.'
concepts.synchronization.dependencies.table.crossQueue.situation: 'Uma fila consome dados produzidos em outra'
concepts.synchronization.dependencies.table.headings.mechanism: 'Mecanismo'
concepts.synchronization.dependencies.table.headings.situation: 'Situação'
-concepts.synchronization.dependencies.table.layoutChange.mechanism: '{commandBufferTransition} com seus layouts anterior e seguinte.'
+concepts.synchronization.dependencies.table.layoutChange.mechanism: 'Chame {commandBufferTransition} com os layouts anterior e seguinte.'
concepts.synchronization.dependencies.table.layoutChange.situation: 'Um sub-recurso de textura altera como é usado'
-concepts.synchronization.dependencies.table.pipelineStages.mechanism: '{commandBufferBarrier} com os estágios produtor e consumidor.'
+concepts.synchronization.dependencies.table.pipelineStages.mechanism: 'Chame {commandBufferBarrier} com os estágios produtor e consumidor.'
concepts.synchronization.dependencies.table.pipelineStages.situation: 'Estágios dependentes da GPU em um fluxo de comandos'
concepts.synchronization.dependencies.title: 'Dependências de acesso'
concepts.synchronization.description: 'A sincronização estabelece a ordem de acesso aos dados compartilhados e garante que operações posteriores vejam os resultados necessários. Em uma dependência de escrita para leitura, quem escreve é o produtor e quem lê é o consumidor. Barreiras e transições de textura coordenam os acessos da GPU; linhas do tempo conectam envios e permitem que a CPU espere a conclusão do trabalho na GPU.'
concepts.synchronization.layouts.context: 'Use {undefined} como layout anterior quando o conteúdo existente puder ser descartado, como em uma imagem nova ou em um anexo que será limpo por completo. Para preservar o conteúdo para carregamento, amostragem ou acumulação, informe o layout do acesso anterior.'
-concepts.synchronization.layouts.description: 'Os indicadores de uso declaram as funções permitidas da textura. {textureLayout} descreve o acesso a um sub-recurso, identificado pelo nível de mip e pela camada do array de texturas, em determinado ponto da sequência de comandos. Quando esse acesso mudar, registre uma transição. No exemplo de computação, a textura de saída é escrita em layout {storage} e depois preparada para amostragem em uma passagem gráfica:'
+concepts.synchronization.layouts.description: 'Os indicadores de uso declaram as funções permitidas da textura. {textureLayout} descreve o acesso a um sub-recurso, identificado pelo nível de mip e pela camada do array de texturas, em determinado ponto da sequência de comandos. Quando esse acesso mudar, grave uma transição. No exemplo de computação, a textura de saída é escrita em layout {storage} e depois preparada para amostragem em uma passagem gráfica:'
concepts.synchronization.layouts.details: 'Aqui, {outputTexture} foi criada com uso {sampledStorage}, e o sub-recurso selecionado está em {storage}. {default} seleciona o nível de mip 0 e a camada 0. A transição não afeta outros níveis ou camadas.'
-concepts.synchronization.layouts.guidance: 'Em {transition}, informe o layout do uso anterior do sub-recurso. A aplicação acompanha esse estado ao registrar comandos e passar texturas entre as etapas de renderização.'
+concepts.synchronization.layouts.guidance: 'Em {transition}, informe o layout do uso anterior do sub-recurso. A aplicação acompanha esse estado ao gravar comandos e passar texturas entre as etapas de renderização.'
concepts.synchronization.layouts.title: 'Layouts de textura'
-concepts.synchronization.readback.description: '{isCompleted} informa a conclusão na GPU. Um download registrado tem uma etapa adicional: copiar o resultado da área interna de leitura para a memória de destino da aplicação.'
-concepts.synchronization.readback.details: '{commandBufferDownload} registra a cópia da GPU para essa área interna. Quando o envio termina, a biblioteca realiza a cópia na CPU ao recuperar o buffer de comandos concluído. Chamar {wait} no valor de envio do download espera a GPU e processa os buffers concluídos daquela fila, completando as duas etapas. Mantenha o destino alocado e a memória gerenciada fixada até o retorno da chamada.'
-concepts.synchronization.readback.guidance: 'Consultar apenas {isCompleted} não executa a cópia final na CPU. Esperar em outra fila também não recupera os buffers concluídos da fila do download. {link} descreve quando uploads e downloads usam acesso direto à memória ou armazenamento temporário de transferência.'
+concepts.synchronization.readback.description: '{isCompleted} informa a conclusão na GPU. Um download gravado no buffer de comandos tem uma etapa adicional: copiar o resultado da área interna de leitura para a memória de destino da aplicação.'
+concepts.synchronization.readback.details: '{commandBufferDownload} grava a cópia da GPU para essa área interna. Quando o envio termina, a biblioteca realiza a cópia na CPU ao recuperar o buffer de comandos concluído. Chamar {wait} no valor de envio do download espera a GPU e processa os buffers concluídos daquela fila, completando as duas etapas. Mantenha o destino alocado e a memória gerenciada fixada até o retorno da chamada.'
+concepts.synchronization.readback.guidance: 'Consultar apenas {isCompleted} não executa a cópia final na CPU. Esperar em outra fila também não recupera os buffers concluídos da fila do download. O artigo {link} descreve quando uploads e downloads usam acesso direto à memória ou armazenamento temporário de transferência.'
concepts.synchronization.readback.guidance.link: 'Gerenciamento de recursos'
concepts.synchronization.readback.title: 'Conclusão da leitura de dados'
concepts.synchronization.reuse.description: 'O triângulo espera cada quadro terminar antes de reutilizar seus dados. Para sobrepor quadros, reserve armazenamento mutável próprio para cada quadro em andamento e acompanhe quando ele volta a estar disponível. Antes de modificar dados, espere o trabalho da GPU que ainda acessa os bytes afetados; antes de liberar um recurso, espere todos os seus usos pendentes.'
-concepts.synchronization.reuse.details: 'Redimensionamento e encerramento seguem a mesma regra: impedir novos usos, esperar os existentes terminarem e então substituir ou liberar os recursos. Respeite essa ordem antes de chamar {swapChainResize} ou liberar recursos ou o contexto. Como o triângulo já espera a cada quadro, ele pode redimensionar entre as chamadas dos callbacks.'
+concepts.synchronization.reuse.details: 'Redimensionamento e encerramento seguem a mesma regra: impedir novos usos, esperar os existentes terminarem e então substituir ou liberar os recursos. Respeite essa ordem antes de chamar {swapChainResize} ou liberar recursos ou o contexto. Como o tutorial do triângulo já espera a cada quadro, o redimensionamento pode ocorrer entre os callbacks.'
concepts.synchronization.reuse.guidance: '{swapChainPresent} sinaliza um ponto da fila gráfica e espera por ele após a apresentação. Assim, o triângulo continua esperando ao apresentar, mesmo sem a espera explícita do envio. O trabalho independente em outras filas precisa de seu próprio acompanhamento de conclusão.'
concepts.synchronization.reuse.title: 'Reutilização de recursos'
concepts.synchronization.timelines.context: 'Se a CPU precisar ler o resultado, sobrescrever os dados compartilhados ou liberar os recursos após o consumidor terminar, espere esse envio:'
concepts.synchronization.timelines.description: 'Uma linha do tempo identifica a conclusão na fila por valores crescentes. {submit} retorna um {timelineValue} contendo a linha do tempo e o valor do envio. Campos {value} de linhas do tempo distintas não são diretamente comparáveis.'
concepts.synchronization.timelines.details: 'Considere {producer} e {consumer}, buffers já gravados em duas filas do mesmo contexto, com o consumidor usando dados escritos pelo produtor. Envie-os com esta dependência:'
-concepts.synchronization.timelines.guidance: 'A fila consumidora espera o valor de conclusão recebido antes de executar seus comandos. A CPU pode continuar sem chamar {producedWait}. Mantenha os recursos compartilhados vivos até a conclusão de {consumed} e registre as transições de textura necessárias ao acesso do consumidor.'
+concepts.synchronization.timelines.guidance: 'A fila consumidora espera o valor de conclusão recebido antes de executar seus comandos. A CPU pode continuar sem chamar {producedWait}. Mantenha os recursos compartilhados vivos até a conclusão de {consumed} e grave as transições de textura necessárias ao acesso do consumidor.'
concepts.synchronization.timelines.notes: 'O valor retornado por {queueTimelineSignal} também pode ser usado para esperar com {wait} ou estabelecer uma dependência para outra fila. {signal} coloca esse ponto de conclusão depois do trabalho já enviado; a GPU o alcança quando esse trabalho termina.'
concepts.synchronization.timelines.title: 'Linhas do tempo e dependências entre filas'
concepts.synchronization.title: 'Sincronização'
@@ -256,7 +254,7 @@ home.entries.reference.category: 'Referência'
home.entries.reference.description: 'Consulte tipos, membros e declarações da API'
home.entries.reference.title: 'Referência da API'
home.entries.samples.action: 'Procurar exemplos'
-home.entries.samples.category: 'Exemplos'
+home.entries.samples.category: 'Exemplos de código'
home.entries.samples.description: 'Exemplos executáveis de técnicas gráficas e de computação'
home.entries.samples.title: 'Exemplos'
home.entries.title: 'Documentação'
@@ -265,13 +263,13 @@ home.entries.tutorial.category: 'Tutorial'
home.entries.tutorial.description: 'De um projeto vazio ao primeiro triângulo na tela'
home.entries.tutorial.title: 'Primeiro triângulo'
home.introduction.accent: 'com .NET'
-home.introduction.description: 'Zenith.NET oferece uma API comum de gráficos e computação para DirectX, Metal e Vulkan'
+home.introduction.description: 'Zenith.NET oferece uma API comum de gráficos e computação para DirectX 12, Metal 4 e Vulkan 1.4'
home.introduction.title: 'Gráficos multiplataforma{lineBreak}{accent}'
-home.meta.description: 'Gráficos e computação multiplataforma em .NET com uma API comum para DirectX, Metal e Vulkan'
+home.meta.description: 'Gráficos e computação multiplataforma em .NET com uma API comum para DirectX 12, Metal 4 e Vulkan 1.4'
home.scene.description: 'Geometria interativa em rotação. Arraste ou use as teclas de direção para ajustar a visualização.'
home.scene.label: 'Exibição de geometria'
home.scene.surface: 'Superfície'
-home.scene.wireframe: 'Wireframe'
+home.scene.wireframe: 'Aramado'
home.title: 'RHI moderna para .NET'
learning.concepts.description: 'Critérios para escolher usos de recursos, descrever dados de shaders e coordenar a execução na GPU'
learning.concepts.execution.description: 'Gravação de comandos, envio e tempo de vida dos recursos'
@@ -282,79 +280,73 @@ learning.concepts.synchronization.description: 'Dependências, visibilidade e co
learning.concepts.title: 'Conceitos fundamentais'
learning.description: 'Comece pelo tutorial do triângulo para criar sua primeira aplicação. Depois, consulte os artigos sobre recursos, dados de shaders e sincronização, ou escolha um exemplo da técnica que deseja implementar.'
learning.entries.samples.action: 'Procurar exemplos'
-learning.entries.samples.description: 'Implementações em C# e Slang de geometria, computação, consultas de raios e sombreamento de malha'
+learning.entries.samples.description: 'Exemplos de geometria, computação, consultas de raios e sombreamento de malha em C# e Slang'
learning.entries.tutorial.action: 'Abrir tutorial'
learning.entries.tutorial.description: 'Uma aplicação de console que abre uma janela e renderiza um triângulo'
learning.meta.description: 'Tutoriais e fundamentos do modelo de programação de Zenith.NET'
learning.title: 'Aprender'
reference.description: 'Referência de recursos, comandos e integrações de plataforma'
reference.entries.commands.description: 'Comandos gráficos, de computação e de transferência'
-reference.entries.commands.label: 'Registrar comandos'
-reference.entries.context.description: 'Criação de recursos da GPU no backend selecionado'
+reference.entries.commands.label: 'Gravar comandos'
+reference.entries.context.description: 'Criação de recursos da GPU por meio de um contexto gráfico'
reference.entries.context.label: 'Comece aqui'
reference.meta.description: 'Namespaces, tipos e membros de Zenith.NET'
reference.navigation.core: 'Referência da API principal'
reference.title: 'Referência da API'
-samples.computeShader.description: 'O exemplo carrega {assetsTexturesShokoPng}, converte a imagem para tons de cinza em um despacho de computação e exibe a textura resultante. A conversão ocorre uma vez; os quadros seguintes exibem o mesmo resultado. O renderizador mostra como vincular texturas para amostragem e escrita, arredondar para cima as quantidades de grupos de threads para cobrir a imagem e verificar seus limites no shader.'
+samples.computeShader.description: 'Um shader de computação converte uma imagem colorida em tons de cinza, demonstrando o processamento de imagens na GPU.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: 'Shader de computação'
-samples.cube.description: 'O cubo acrescenta desenho indexado, matrizes de modelo, visão e projeção em um buffer de constantes e teste de profundidade. Sua textura de profundidade e estêncil {d32FloatS8UInt} é recriada no redimensionamento.'
+samples.cube.description: 'Um cubo em rotação demonstra o uso de geometria indexada, transformações 3D e teste de profundidade.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: 'Cubo giratório'
-samples.description: 'Cada exemplo reúne um renderizador C# e seu shader Slang em torno de uma técnica. Para a configuração completa da aplicação e a sequência de renderização, comece por {link}.'
-samples.description.link: 'Primeiro triângulo'
+samples.description: 'Os exemplos abrangem renderização e computação, desde um único triângulo até aplicações interativas e ferramentas de diagnóstico.'
samples.execution.description: 'Execute o projeto {link} e escolha um exemplo no menu do console.'
samples.execution.description.link: 'ZenithTutorials'
samples.execution.title: 'Execução dos exemplos'
-samples.host.description: '{appCs} inicializa contexto, janela e cadeia de troca. A cada quadro, obtém um buffer de comandos, chama o renderizador selecionado, envia os comandos e apresenta o resultado. {iRendererCs} define as operações de atualização, renderização, redimensionamento e liberação.'
-samples.host.details: 'Os renderizadores de computação e traçado de raios produzem texturas fora da tela. {texturePresenterCs} e {presentTextureSlang} desenham essas texturas na saída do quadro atual; em seguida, o programa hospedeiro compartilhado envia os comandos e apresenta o quadro.'
-samples.host.title: 'Programa hospedeiro e apresentação'
-samples.indirectDrawing.description: 'O desenho indireto renderiza várias instâncias de cubos a partir de um buffer de argumentos de desenho indexado e de um buffer estruturado de dados por instância. A CPU fornece os argumentos e atualiza as transformações.'
+samples.indirectDrawing.description: 'Uma grade de cubos giratórios, cada um com sua cor, demonstra o desenho indireto a partir de um buffer de argumentos de desenho.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: 'Desenho indireto'
-samples.meshShading.description: 'Um shader de tarefa descarta as instâncias de esferas não visíveis e passa os índices restantes ao shader de malha, que gera a geometria. O renderizador verifica {contextCapabilitiesMeshShadingSupported} antes de criar o pipeline.'
+samples.meshShading.description: 'Este exemplo usa shaders de tarefa e de malha para renderizar uma grade de esferas coloridas, ignorando as que estão fora do campo de visão da câmera. Requer suporte a sombreamento de malha.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: 'Sombreamento de malha'
-samples.rayTracing.description: 'O exemplo cria estruturas de aceleração de nível inferior e superior para um piso e esferas procedurais e realiza consultas de raios em um shader de computação. Verifica {contextCapabilitiesRayTracingSupported} antes da inicialização.'
+samples.rayTracing.description: 'Este exemplo usa consultas de raios para renderizar esferas com reflexos e sombras sobre um piso quadriculado. Requer suporte a traçado de raios.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: 'Traçado de raios'
samples.title: 'Exemplos'
-samples.triangle.description: 'O triângulo associa um buffer de vértices ao layout de entrada correspondente e desenha três vértices por um pipeline gráfico.'
+samples.triangle.description: 'Um triângulo com transições suaves entre as cores dos vértices apresenta o pipeline gráfico básico.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: 'Tutorial completo'
-samples.triangle.title: 'Olá triângulo'
-samples.workloads.description: 'O {link} do repositório principal contém aplicações de maior porte que referenciam o código-fonte da biblioteca.'
+samples.triangle.title: 'Olá, triângulo'
+samples.workloads.description: 'O {link} do repositório Zenith.NET contém as aplicações e os utilitários a seguir.'
samples.workloads.description.link: 'diretório Experiments'
-samples.workloads.details: 'Os experimentos com janela usam os mesmos mecanismos de apresentação em Windows, macOS e Linux/X11. {link} trata dos controles para Avalonia, WinForms, WPF, WinUI/Uno e MAUI, incluindo o ciclo dos quadros e as implementações.'
-samples.workloads.details.link: 'Integração de plataforma'
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: 'CornellBox'
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Traçado de caminhos, redução de ruído, mapeamento de tons, ampliação de resolução e controles ImGui. Requer suporte a traçado de raios.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Uma cena interativa de uma sala para explorar a iluminação e os reflexos. Requer suporte a traçado de raios.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: 'FluidTank'
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Simulação de fluidos por computação, dependências entre estágios de simulação e renderização de superfície em várias passagens.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Uma simulação de água em um tanque, com visualizações da superfície e das partículas.'
samples.workloads.table.headings.example: 'Exemplo'
-samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Técnicas e requisitos'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Descrição'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: 'InkCanvas'
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'Desenho com Skia e tratamento de entrada em uma janela nativa. Requer o backend e a biblioteca nativa do Skia para a plataforma de destino.'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: 'Uma tela para desenhar e apagar traços à mão livre.'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: 'PlatformDetection'
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Tenta criar um contexto para cada backend e informa as capacidades do dispositivo. Uma tentativa que falha é indicada como não compatível; a causa pode estar no dispositivo, no driver ou em uma dependência de execução ausente.'
-samples.workloads.title: 'Aplicações de maior porte'
-tutorial.context.description: 'Um {graphicsContext} conecta a aplicação à GPU por meio de um backend e fornece os métodos para criar os recursos de renderização.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Uma ferramenta de console que mostra quais APIs gráficas estão disponíveis e as funcionalidades do dispositivo.'
+samples.workloads.title: 'Aplicações e utilitários'
+tutorial.context.description: 'Um {graphicsContext} conecta a aplicação à GPU por meio da API gráfica escolhida e fornece métodos para criar recursos de renderização.'
tutorial.context.details: 'Insira a inicialização do contexto {emphasis}:'
tutorial.context.details.emphasis: 'após as diretivas using, antes de {iWindowWindow}'
-tutorial.context.guidance: 'Cada ramo seleciona o backend da plataforma e solicita a validação. As mensagens de {validationMessage} são exibidas no console.'
+tutorial.context.guidance: 'Cada ramo solicita a validação para sua API gráfica. O manipulador exibe no console os diagnósticos de {validationMessage} quando a implementação os fornece.'
tutorial.context.imports: 'Adicione as seguintes diretivas using no início de {programCs}:'
tutorial.context.title: 'Contexto gráfico'
-tutorial.description: 'Neste tutorial, um projeto de console .NET vazio se torna uma aplicação que abre uma janela e desenha um triângulo colorido.'
+tutorial.description: 'Neste tutorial, você criará uma aplicação de console .NET que abre uma janela e desenha um triângulo colorido, começando por um projeto vazio.'
tutorial.details: 'O tutorial tem três pontos de verificação: uma janela vazia, um fundo de cor uniforme e o triângulo colorido. Execute a aplicação em cada ponto antes de acrescentar a próxima parte.'
tutorial.draw.context: 'Os argumentos para {draw} são:'
tutorial.draw.description: 'No callback {windowRender}, substitua {addTheTriangleDrawCommandsHereLater} pelos comandos abaixo, entre {beginRenderPass} e {endRenderPass}:'
-tutorial.draw.details: '{setPipeline} seleciona shaders e estado de renderização. Deve preceder o vínculo dos vértices, pois o backend interpreta esse vínculo conforme o layout de entrada do pipeline.'
-tutorial.draw.guidance: '{setVertexBufferVertexBuffer} vincula os dados de vértices já transferidos, a partir do deslocamento de byte 0, ao slot de entrada 0, correspondente à única entrada de {inputLayouts}.'
-tutorial.draw.notes: 'Essas chamadas registram os comandos de desenho. A chamada existente a {submitWait} os envia e espera a GPU terminar; em seguida, {present} solicita a exibição da imagem concluída. Mantenha a limpeza no início da passagem para definir a cor de fundo na área externa ao triângulo.'
+tutorial.draw.details: '{setPipeline} seleciona os shaders e o estado de renderização. Vincule o pipeline antes do buffer de vértices para que seu layout de entrada determine como os dados dos vértices serão lidos.'
+tutorial.draw.guidance: '{setVertexBufferVertexBuffer} vincula o buffer de vértices já preenchido, a partir do deslocamento de byte 0, ao slot de entrada 0, correspondente à única entrada de {inputLayouts}.'
+tutorial.draw.notes: 'Mantenha a limpeza no início da passagem para definir a cor de fundo na área externa ao triângulo.'
tutorial.draw.table.firstInstance.meaning: 'Iniciar a numeração de instâncias em zero.'
tutorial.draw.table.firstVertex.meaning: 'Começar com o primeiro vértice no buffer.'
tutorial.draw.table.headings.argument: 'Argumento'
@@ -367,43 +359,42 @@ tutorial.execution.description: 'Compile e execute o projeto {firstTriangle}.'
tutorial.execution.details: 'A janela deve exibir um triângulo sobre fundo escuro, vermelho no alto, verde embaixo à direita e azul embaixo à esquerda. A interpolação das cores dos vértices forma um gradiente suave em seu interior.'
tutorial.execution.guidance: 'O redimensionamento muda as dimensões da imagem em pixels, mas mantém as coordenadas dos vértices. O viewport ajusta essas coordenadas à nova largura e altura, por isso o triângulo se deforma quando a proporção da janela muda.'
tutorial.execution.title: 'Execução da aplicação'
-tutorial.frame.commands.context: 'Após {endRenderPass}, a segunda transição prepara a textura de saída para apresentação. {submit} encerra o registro e envia o buffer de comandos; {wait} bloqueia a thread até a conclusão desse envio. Em seguida, {present} solicita a exibição da imagem renderizada.'
-tutorial.frame.commands.description: 'Uma passagem de renderização reúne operações de desenho que escrevem nos mesmos anexos. Nesta passagem, a textura de saída da cadeia de troca recebe a cor. {colorAttachmentClear} descreve como inicializar esse anexo com uma cor RGBA e preservar seu conteúdo ao encerrar a passagem. {beginRenderPass} registra o início da passagem com essas configurações.'
+tutorial.frame.commands.context: 'Após {endRenderPass}, a segunda transição prepara a textura de saída para apresentação. {submit} encerra a gravação e envia o buffer de comandos; {wait} bloqueia a thread até a conclusão desse envio. Em seguida, {present} solicita a exibição da imagem renderizada.'
+tutorial.frame.commands.description: 'Uma passagem de renderização reúne operações de desenho que escrevem nos mesmos anexos. Nesta passagem, o resultado de cor é escrito na textura de saída da cadeia de troca. {colorAttachmentClear} descreve como inicializar esse anexo com uma cor RGBA e preservar seu conteúdo ao encerrar a passagem. {beginRenderPass} grava o início da passagem com essas configurações.'
tutorial.frame.commands.details: 'A coleção contém um anexo de cor. {null} indica que a passagem não possui anexo de profundidade e estêncil.'
-tutorial.frame.commands.guidance: '{beginRenderPass} ajusta o viewport e a região de recorte para todo o anexo. O viewport converte coordenadas de renderização em posições de pixels; o recorte limita a região em que se pode escrever.'
+tutorial.frame.commands.guidance: '{beginRenderPass} ajusta o viewport e a região de recorte para todo o anexo. O viewport converte coordenadas de renderização em posições de pixels; o recorte limita os pixels que as operações de desenho podem afetar.'
tutorial.frame.commands.title: 'Limpeza, envio e apresentação'
-tutorial.frame.description: 'Comece preenchendo a janela com uma cor de fundo. Essa operação é chamada de limpeza. Quando o fundo aparece, a superfície, o envio de comandos e a apresentação já funcionam juntos. A partir daí, acrescente os vértices e os shaders do triângulo.'
-tutorial.frame.details: 'Silk.NET chama o callback quando há um quadro a renderizar. Como o exemplo não usa o argumento de tempo decorrido, o parâmetro se chama {value}. Registre o callback {emphasis}:'
+tutorial.frame.description: 'Comece preenchendo a janela com uma cor uniforme. Essa operação é chamada de limpeza. Se a cor aparecer, o envio de comandos e a apresentação estão funcionando. Depois, acrescente os vértices e os shaders do triângulo.'
+tutorial.frame.details: 'Silk.NET chama o callback de renderização quando há um quadro a renderizar. Registre o callback {emphasis}:'
tutorial.frame.details.emphasis: 'antes de {windowRun}'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} retorna um buffer pronto para gravação. Gravar define o trabalho da GPU; sua execução só começa após o envio.'
+tutorial.frame.target.description: 'Uma fila de comandos recebe o trabalho gravado para execução na GPU. {graphicsQueueCommandBuffer} retorna um buffer de comandos da fila gráfica cuja gravação já está em andamento. Os comandos gravados definem o trabalho da GPU; a execução só começa após o envio.'
tutorial.frame.target.details: 'O layout de uma textura descreve o acesso necessário a uma operação. A primeira chamada a {transition} prepara a textura de saída para uso como anexo de cor. Aqui, {default} seleciona o nível de mip 0 e a camada 0 do array, ou seja, a imagem base da textura. Como a passagem limpa a imagem inteira, {undefined} permite descartar o conteúdo anterior.'
tutorial.frame.target.guidance: 'Obtenha a textura de saída atual a cada quadro, pois a apresentação pode passar a usar outra imagem.'
tutorial.frame.target.title: 'Preparação da textura de saída'
tutorial.frame.title: 'O primeiro quadro'
tutorial.geometry.data.description: 'Adicione o array de vértices {emphasis}. Mantenha também as próximas inicializações de recursos antes desse callback, na ordem apresentada.'
tutorial.geometry.data.description.emphasis: 'antes de {windowRender}'
-tutorial.geometry.data.details: 'Cada entrada constrói um {vertex}; os dois {new} internos fornecem a posição {vector3} e a cor {vector4}. As posições formam os cantos superior, inferior direito e inferior esquerdo. O shader de vértices acrescenta {w} como quarta coordenada. Com w igual a 1, x e y também são coordenadas normalizadas de dispositivo: -1 e +1 marcam os limites da imagem, e 0, o centro. Sua interpretação independe da quantidade de pixels.'
+tutorial.geometry.data.details: 'As três posições formam os cantos superior, inferior direito e inferior esquerdo. Neste exemplo, a faixa de coordenadas da imagem vai de -1 a +1 em x e y: 0 é o centro, o sentido positivo de x aponta para a direita e o de y, para cima.'
tutorial.geometry.data.guidance: 'Cada cor tem componentes vermelho, verde, azul e alfa, com alfa igual a 1. Os três vértices têm z = 0 e estão no mesmo plano.'
tutorial.geometry.data.title: 'Posições e cores dos vértices'
tutorial.geometry.description: 'Cada um dos três vértices tem posição e cor. A GPU determina a forma do triângulo a partir das posições e interpola as cores em sua superfície.'
-tutorial.geometry.format.description: 'Acrescente a declaração do vértice {emphasis}:'
+tutorial.geometry.format.description: 'Acrescente a declaração do tipo de vértice {emphasis}:'
tutorial.geometry.format.description.emphasis: 'no final de {programCs}, após as instruções de limpeza'
-tutorial.geometry.format.details: '{file} restringe o tipo a {programCs}, e {layoutKindSequential} mantém os campos na ordem de declaração. {position} contém três valores de ponto flutuante de 32 bits e começa no deslocamento de byte 0; {color} contém quatro e começa no deslocamento de byte 12. Cada vértice ocupa, portanto, 28 bytes. O layout de entrada descreverá essa organização para que a GPU leia os campos corretamente.'
+tutorial.geometry.format.details: '{layoutKindSequential} mantém os campos na ordem de declaração. {position} contém três valores de ponto flutuante de 32 bits e começa no deslocamento de byte 0; {color} contém quatro e começa no deslocamento de byte 12. Cada vértice ocupa, portanto, 28 bytes. O layout de entrada descreverá essa organização para que a GPU leia os campos corretamente.'
tutorial.geometry.format.imports: 'Adicione estas diretivas using no início de {programCs} para usar os tipos vetoriais e o atributo de layout da estrutura:'
tutorial.geometry.format.title: 'Representação dos vértices'
tutorial.geometry.title: 'Dados de vértices'
-tutorial.geometry.upload.context: '{fixed} impede que o coletor de lixo mova o array enquanto seu endereço estiver em uso. Neste buffer gravável pela CPU, {upload} mapeia a memória, copia os bytes e desfaz o mapeamento antes de retornar. O array só precisa permanecer fixado durante a chamada. Envie os vértices uma vez na inicialização e mantenha o buffer vivo até o fim da renderização.'
-tutorial.geometry.upload.description: 'Armazene os vértices em um {buffer} para que a GPU possa lê-los durante o desenho. Acrescente a alocação e o envio dos dados logo após o array:'
-tutorial.geometry.upload.details: 'O tamanho é {sizeofVertexVerticesLength}: três vértices de 28 bytes, ou 84 bytes. {bufferUsagesVertex} declara o uso como entrada de vértices, e {cpuWriteOnly} permite a inicialização direta pela CPU. O passo do descritor registra o tamanho do elemento. O layout definido adiante especifica como cada atributo será lido.'
+tutorial.geometry.upload.context: '{fixed} impede que o coletor de lixo mova o array enquanto seu endereço estiver em uso. Neste buffer gravável pela CPU, {upload} mapeia a memória, copia os bytes e desfaz o mapeamento antes de retornar. O array só precisa permanecer fixado durante a chamada. Faça o upload dos vértices uma vez na inicialização e mantenha o buffer vivo até o fim da renderização.'
+tutorial.geometry.upload.description: 'Armazene os vértices em um {buffer} para que a GPU possa lê-los durante o desenho. Acrescente a alocação e o upload dos dados logo após o array:'
+tutorial.geometry.upload.details: 'O tamanho é {sizeofVertexVerticesLength}: três vértices de 28 bytes, ou 84 bytes. {bufferUsagesVertex} declara o uso como entrada de vértices, e {cpuWriteOnly} permite a inicialização direta pela CPU. O passo do descritor informa o tamanho do elemento. O layout definido adiante especifica como cada atributo será lido.'
tutorial.geometry.upload.guidance: 'A alocação não inicializa o conteúdo do buffer. {upload} copia o array para o deslocamento 0 do destino, usando o ponteiro de origem e a quantidade de bytes da descrição de dados.'
tutorial.geometry.upload.imports: 'Em {programCs}, adicione {bufferAlias} às diretivas using para distinguir o tipo de buffer do Zenith.NET de {systemBuffer}.'
-tutorial.geometry.upload.notes: 'Na limpeza ao final de {programCs}, insira {vertexBufferDispose} imediatamente antes de {swapChainDispose}. {link} trata do armazenamento exclusivo da GPU e de transferências para geometria estática maior.'
-tutorial.geometry.upload.notes.link: 'Gerenciamento de recursos'
-tutorial.geometry.upload.title: 'Alocação e transferência do buffer'
+tutorial.geometry.upload.notes: 'Na limpeza ao final de {programCs}, insira {vertexBufferDispose} imediatamente antes de {swapChainDispose}.'
+tutorial.geometry.upload.title: 'Alocação do buffer e upload dos dados'
tutorial.input.description: 'A GPU precisa saber onde estão os atributos de cada vértice, como posição e cor. O layout de entrada fornece o formato e o deslocamento de cada atributo, além do passo: a distância em bytes até o próximo vértice. Adicione este código após criar os shaders:'
tutorial.input.details: '{inputLayoutAdd} coloca cada atributo após o anterior e soma seu tamanho ao passo entre vértices. Os deslocamentos são calculados a partir dos formatos informados, sem inspecionar a estrutura C#. Para esses dois campos, o resultado é:'
tutorial.input.guidance: 'O valor padrão de {semanticIndex} é zero, correspondente a {pOSITION0} e {cOLOR0} no shader. Posição e cor ficam juntas em um buffer de vértices, portanto o pipeline utiliza um único layout de entrada no slot 0. Se a ordem dos campos ou o preenchimento da estrutura C# mudar, ajuste também esse layout.'
-tutorial.input.table.headings.byteOffset: 'Deslocamento de bytes'
+tutorial.input.table.headings.byteOffset: 'Deslocamento em bytes'
tutorial.input.table.headings.cField: 'Campo C#'
tutorial.input.table.headings.format: 'Formato'
tutorial.input.table.headings.shaderInput: 'Entrada do shader'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: 'Próximo registro de entrada'
tutorial.input.table.vertexColor.format: '{float4} (16 bytes)'
tutorial.input.table.vertexPosition.format: '{float3} (12 bytes)'
tutorial.input.title: 'Layout de entrada dos vértices'
-tutorial.lifecycle.description: 'Cada quadro segue esta sequência:'
-tutorial.lifecycle.details: 'Quando a janela fecha, {run} retorna e a execução continua no código de limpeza. Como cada quadro já esperou seus comandos terminarem, os recursos usados por eles podem ser liberados. O bloco completo de limpeza após {windowRun} é:'
+tutorial.lifecycle.description: 'A cada quadro, a aplicação obtém a textura de saída atual, faz sua transição para renderização, limpa-a e desenha o triângulo. Depois, faz a transição da textura para apresentação, envia os comandos gravados, aguarda a conclusão do trabalho na GPU e apresenta a imagem.'
+tutorial.lifecycle.details: 'Quando a janela fecha, {run} retorna e a execução continua no código de limpeza. Como o callback de renderização já aguardou a conclusão de todos os quadros enviados, os recursos usados pelos comandos podem ser liberados. O bloco completo de limpeza após {windowRun} é:'
tutorial.lifecycle.guidance: 'Libere a cadeia de troca antes de destruir sua janela nativa e o contexto depois de seus recursos. A fila recicla os buffers de comandos enviados, e a cadeia de troca gerencia a textura de saída; nenhum deles precisa de uma chamada separada a {dispose}.'
-tutorial.lifecycle.title: 'Ciclo dos quadros e liberação'
tutorial.pipeline.behavior: 'Após o layout de entrada, crie o pipeline:'
tutorial.pipeline.context: '{cullNone} desativa o descarte de faces, de modo que o triângulo seja desenhado tanto com os vértices em sentido horário quanto em sentido anti-horário.'
tutorial.pipeline.description: 'Um {graphicsPipeline} reúne o layout dos vértices, os dois shaders e as configurações de montagem de primitivas e escrita nos anexos.'
-tutorial.pipeline.details: 'Os shaders processam vértices e fragmentos. As demais configurações do pipeline controlam a montagem de primitivas, o descarte de faces, o teste de profundidade e a mesclagem de cores:'
tutorial.pipeline.guidance: 'O formato de cor do pipeline deve corresponder ao anexo da passagem, por isso é obtido de {swapChainDescFormat}. {count1} especifica uma amostra por pixel.'
tutorial.pipeline.item: '{triangleList} monta um triângulo a cada grupo de três vértices consecutivos.'
tutorial.pipeline.notes: '{depthNone} desativa teste e escrita de profundidade, de acordo com a ausência desse anexo.'
@@ -428,30 +417,27 @@ tutorial.pipeline.reference: '{opaque} desativa a mesclagem. A saída do shader
tutorial.pipeline.title: 'Pipeline gráfico'
tutorial.pipeline.usage: 'Os objetos de shader podem ser liberados após a criação do pipeline. Mantenha o pipeline durante a renderização e adicione {pipelineDispose} antes de {vertexBufferDispose} na limpeza.'
tutorial.presentation.title: 'Contexto gráfico e apresentação'
-tutorial.project.context: 'Ative {emphasis} ({allowUnsafeBlocks}) nas opções de compilação do projeto. As chamadas nativas do auxiliar de janela e a transferência de vértices exigem código não seguro.'
+tutorial.project.context: 'Ative {emphasis} ({allowUnsafeBlocks}) nas opções de compilação do projeto. As chamadas nativas da classe auxiliar da janela e o upload dos vértices exigem código não seguro.'
tutorial.project.context.emphasis: 'Permitir código não seguro'
tutorial.project.description: 'Crie um projeto de console C# chamado {firstTriangle}, com .NET 10 como framework de destino.'
tutorial.project.details: 'Adicione os seguintes pacotes NuGet ao projeto:'
-tutorial.project.guidance: '{zenithNET} fornece a API comum de renderização; os três pacotes de backend, suas implementações. {zenithNETCompiler} compila os shaders Slang apresentados adiante para o backend selecionado. Silk.NET cria a janela e processa eventos.'
+tutorial.project.guidance: '{zenithNET} fornece a API comum para gráficos e computação; os três pacotes de API gráfica a implementam. {zenithNETCompiler} compila shaders Slang para a API escolhida.'
tutorial.project.title: 'Configuração do projeto'
-tutorial.requirements.context: 'O {link} e seu {detail} fornecem as implementações de referência deste tutorial.'
-tutorial.requirements.context.detail: 'programa hospedeiro'
-tutorial.requirements.context.link: 'exemplo Olá triângulo'
-tutorial.requirements.description: 'São necessários o {emphasis} e conhecimentos básicos de C#. A aplicação tem {net10} como destino. A GPU e o driver devem oferecer suporte ao backend escolhido para sua plataforma:'
+tutorial.requirements.description: 'São necessários o {emphasis} e conhecimentos básicos de C#. A GPU e o driver devem oferecer o suporte gráfico indicado para sua plataforma:'
tutorial.requirements.description.emphasis: 'SDK do .NET 10'
-tutorial.requirements.guidance: 'Zenith.NET renderiza em uma superfície nativa fornecida pela aplicação. Silk.NET.Windowing cria a janela e processa seus eventos. No macOS, a apresentação usa uma camada Metal, representada por {cAMetalLayerCs}, que o auxiliar associa à janela.'
-tutorial.requirements.table.headings.graphicsBackend: 'Backend gráfico'
+tutorial.requirements.guidance: 'Zenith.NET renderiza em uma superfície nativa fornecida pela aplicação. Silk.NET.Windowing cria a janela e processa seus eventos.'
+tutorial.requirements.table.headings.graphicsBackend: 'Suporte gráfico'
tutorial.requirements.table.headings.platform: 'Plataforma'
-tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4'
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 com VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux (X11 ou XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: 'Metal 4'
tutorial.requirements.table.macOS.platform: 'macOS'
-tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12'
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 com Shader Model 6.6'
tutorial.requirements.table.windows.platform: 'Windows'
tutorial.requirements.title: 'Pré-requisitos'
-tutorial.resize.context: 'Compile e execute a aplicação novamente. O fundo deve continuar preenchendo a janela quando ela for redimensionada: cada nova passagem ajusta o viewport e o retângulo de recorte às dimensões do anexo. Mantenha o callback de renderização; o triângulo será desenhado dentro dessa mesma passagem.'
+tutorial.resize.context: 'Compile e execute a aplicação novamente. O fundo deve continuar preenchendo a janela quando ela for redimensionada. Mantenha o callback de renderização; o triângulo será desenhado dentro dessa mesma passagem.'
tutorial.resize.description: 'A cadeia de troca precisa acompanhar as mudanças de tamanho do framebuffer. Registre um callback de {framebufferResize} depois do callback de renderização e antes de {windowRun}:'
-tutorial.resize.details: 'Responda às {link}, medidas em pixels, em vez de às mudanças no tamanho lógico da janela. Se minimizar a janela fizer alguma dimensão chegar a zero, o callback de redimensionamento mantém a cadeia de troca como está. O callback de renderização também retorna enquanto alguma dimensão for zero, interrompendo a renderização até que o framebuffer volte a ter um tamanho utilizável.'
+tutorial.resize.details: 'Responda às {link}, expressas em pixels, e não às mudanças no tamanho lógico da janela. Se a largura ou a altura do framebuffer chegar a zero ao minimizar a janela, o callback de redimensionamento mantém a cadeia de troca como está. O callback de renderização também retorna enquanto alguma dimensão for zero, interrompendo a renderização até que o framebuffer volte a ter um tamanho utilizável.'
tutorial.resize.details.link: 'alterações no tamanho do framebuffer'
tutorial.resize.guidance: 'O callback de renderização espera cada quadro enviado terminar antes de chamar {present}. Assim, o callback de redimensionamento pode substituir as imagens da cadeia de troca sem interromper o trabalho de um quadro anterior. O artigo {link} detalha essa relação entre a conclusão do trabalho e o tempo de vida dos recursos.'
tutorial.resize.guidance.link: 'Sincronização'
@@ -460,52 +446,34 @@ tutorial.shaders.compilation.context: '{appContextBaseDirectory} permite carrega
tutorial.shaders.compilation.description: 'Nas propriedades de {triangleSlang}, defina {emphasis} como {detail}. A compilação copiará o shader para o diretório do executável.'
tutorial.shaders.compilation.description.detail: 'Copiar se mais recente'
tutorial.shaders.compilation.description.emphasis: 'Copiar para o Diretório de Saída'
-tutorial.shaders.compilation.details: 'Em {programCs}, acrescente a inicialização dos shaders após a transferência dos vértices e antes do callback de renderização:'
-tutorial.shaders.compilation.guidance: '{zenithCompiler} compila o código-fonte para {contextGraphicsApi}, e {createShader} cria um objeto shader a partir da descrição compilada. Os nomes de ponto de entrada {vSMain} e {fSMain} selecionam as duas funções definidas no arquivo Slang.'
+tutorial.shaders.compilation.details: 'Em {programCs}, acrescente a inicialização dos shaders após o upload dos vértices e antes do callback de renderização:'
+tutorial.shaders.compilation.guidance: '{zenithCompiler} compila o código-fonte para {contextGraphicsApi}, e {createShader} cria um objeto de shader a partir da descrição compilada. Os nomes de ponto de entrada {vSMain} e {fSMain} selecionam as duas funções definidas no arquivo Slang.'
tutorial.shaders.compilation.title: 'Compilação dos shaders'
tutorial.shaders.context: '{fSInput} conecta as duas etapas do shader. O shader de vértices escreve em {sVPOSITION} uma posição no espaço de recorte, que a GPU usa para determinar a parte visível do triângulo. O campo {cOLOR0} leva a cor do vértice, interpolada ao longo do triângulo antes de chegar ao shader de fragmentos. Seu tipo e sua semântica devem corresponder nas duas etapas.'
tutorial.shaders.description: 'Shaders são programas executados na GPU. O shader de vértices determina a posição de cada vértice, e o shader de fragmentos determina a cor em cada posição coberta da imagem. As duas etapas serão escritas em um único arquivo Slang, cada uma com seu ponto de entrada: a função em que a execução começa.'
-tutorial.shaders.details: 'Crie {triangleSlang} com estas estruturas de entrada e saída:'
+tutorial.shaders.details: 'Crie {triangleSlang} na raiz do projeto com estas estruturas de entrada e saída:'
tutorial.shaders.fragment.description: 'Acrescente o ponto de entrada de fragmentos ao mesmo arquivo:'
tutorial.shaders.fragment.details: 'A rasterização identifica as posições da imagem cobertas pelo triângulo e gera fragmentos para elas. Cada fragmento recebe uma cor interpolada a partir das cores dos três vértices. {fSMain} retorna essa cor, e {sVTARGET} direciona o resultado ao primeiro anexo de cor.'
tutorial.shaders.fragment.title: 'Sombreamento de fragmentos'
tutorial.shaders.guidance: '{vSInput} define as entradas do shader de vértices. {pOSITION0} e {cOLOR0} identificam os atributos por semântica; nomes de campos em C# não estabelecem sozinhos essa correspondência.'
tutorial.shaders.title: 'Estágios dos shaders'
tutorial.shaders.vertex.description: 'Acrescente o ponto de entrada de vértices a {triangleSlang}:'
-tutorial.shaders.vertex.details: 'A GPU executa esse ponto de entrada para cada vértice. Ele acrescenta a coordenada homogênea {w} e repassa a cor. Após o processamento dos vértices, a posição é dividida por w. Como w vale 1, x, y e z permanecem iguais e podem ser interpretados como coordenadas normalizadas de dispositivo.'
+tutorial.shaders.vertex.details: 'A GPU executa esta função para cada vértice de entrada. A função acrescenta um quarto componente à posição, {w}, e repassa a cor. Após processar os vértices, a GPU divide x, y e z por w para obter as coordenadas normalizadas de dispositivo. Como w vale 1, esses valores não mudam.'
tutorial.shaders.vertex.title: 'Sombreamento de vértices'
tutorial.surface.description: 'Especifique o destino nativo de apresentação {emphasis}:'
tutorial.surface.description.emphasis: 'após {windowCenter} e antes de {windowRun}'
tutorial.surface.details: 'O framebuffer é a imagem da janela em pixels. {surface} descreve o destino nativo de apresentação e suas dimensões; {framebufferSize} fornece o tamanho em pixels. Com a escala da tela, esse tamanho pode diferir das dimensões lógicas da janela.'
-tutorial.surface.guidance: 'A superfície fornece os identificadores nativos do backend: uma janela Win32 no Windows, display e janela X11 no Linux ou a camada Metal associada no macOS.'
+tutorial.surface.guidance: 'A descrição da superfície contém os identificadores nativos exigidos pela API gráfica: uma janela Win32 no Windows, um display e uma janela X11 no Linux ou a camada Metal associada no macOS.'
tutorial.surface.title: 'Superfície nativa'
tutorial.swapChain.context: 'A cadeia de troca depende do contexto e da janela. Substitua {windowDispose} no final de {programCs} por esta ordem de liberação:'
tutorial.swapChain.description: 'Crie a cadeia de troca logo após a descrição da superfície:'
tutorial.swapChain.details: 'A {swapChain} gerencia as imagens apresentadas pela janela. {drawable} fornece a imagem atual como uma {texture}, o recurso de imagem da API. Após a renderização, {present} solicita sua exibição e avança para a próxima textura de saída.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} armazena quatro canais de 8 bits na ordem azul, verde, vermelho e alfa. {uNorm} mapeia os inteiros de 0–255 para 0–1. A saída do shader continua sendo um valor RGBA lógico; o formato define sua representação no armazenamento. O pipeline usará {swapChainDescFormat} para corresponder a esse anexo.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} armazena quatro canais de 8 bits na ordem azul, verde, vermelho e alfa. {uNorm} mapeia os valores inteiros de 0–255 para valores de 0–1. A saída do shader continua sendo um valor RGBA lógico; o formato especifica sua representação na memória.'
tutorial.swapChain.title: 'Cadeia de troca'
tutorial.title: 'Primeiro triângulo'
-tutorial.troubleshooting.description: 'Use os diagnósticos do console e os três pontos de verificação para localizar a etapa com falha:'
-tutorial.troubleshooting.details: 'O {link} e o {detail} servem de referência para dados de vértices, layout e desenho. O exemplo separa janela e envio em um programa hospedeiro comum; este tutorial mantém o fluxo em {programCs}. O {context} introduz desenho indexado, transformações e teste de profundidade.'
-tutorial.troubleshooting.details.context: 'Cubo giratório'
-tutorial.troubleshooting.details.detail: 'shader Slang'
-tutorial.troubleshooting.details.link: 'renderizador de exemplo'
-tutorial.troubleshooting.table.backend.check: 'Verifique se o backend selecionado é suportado pelo dispositivo e pelo driver gráfico instalado.'
-tutorial.troubleshooting.table.backend.symptom: 'Falha na criação do backend'
-tutorial.troubleshooting.table.drawing.check: 'Verifique o tamanho do upload, o layout de entrada, a seleção de pipeline e o posicionamento dos comandos de desenho dentro da passagem de renderização.'
-tutorial.troubleshooting.table.drawing.symptom: 'O fundo aparece, mas o triângulo não'
-tutorial.troubleshooting.table.headings.check: 'Verificação'
-tutorial.troubleshooting.table.headings.symptom: 'Sintoma'
-tutorial.troubleshooting.table.input.check: 'Verifique o passo de 28 bytes e os deslocamentos de posição/cor de 0 e 12.'
-tutorial.troubleshooting.table.input.symptom: 'Posições ou cores dos vértices estão corrompidas'
-tutorial.troubleshooting.table.shaders.check: 'Verifique o {triangleSlang} copiado, a ortografia do ponto de entrada e o diagnóstico relatado pelo compilador.'
-tutorial.troubleshooting.table.shaders.symptom: 'O fundo aparece, mas o carregamento dos shaders falha'
-tutorial.troubleshooting.table.window.check: 'Confirme se o projeto .NET compila e se a etapa somente de janela é executada em uma sessão de desktop. No Linux, verifique se o X11 ou XWayland está disponível.'
-tutorial.troubleshooting.table.window.symptom: 'Nenhuma janela se abre'
-tutorial.troubleshooting.title: 'Diagnóstico de problemas'
tutorial.window.description: 'Baixe {cocoaHelperCs} para o diretório do projeto. Essa classe auxiliar conecta a camada Metal à janela do macOS.'
-tutorial.window.details: 'Substitua o conteúdo gerado de {programCs} pelo código abaixo. Ele usa instruções de nível superior, executadas em ordem sem um método {main} explícito. As próximas seções indicarão onde acrescentar cada trecho:'
-tutorial.window.guidance: '{graphicsAPINone} deixa a criação do contexto gráfico a cargo de Zenith.NET. {initialize} cria a janela nativa e disponibiliza os identificadores do sistema de janelas. {center} a coloca no centro da tela. {run} processa eventos até seu fechamento; depois, {dispose} libera a janela.'
+tutorial.window.details: 'Substitua o conteúdo de {programCs} pelo código abaixo:'
+tutorial.window.guidance: '{graphicsAPINone} impede que Silk.NET crie um contexto gráfico próprio para a janela; a aplicação criará depois um contexto do Zenith.NET. {initialize} cria a janela nativa e disponibiliza os identificadores do sistema de janelas. {center} a coloca no centro da tela. {run} processa eventos até seu fechamento; depois, {dispose} libera a janela.'
tutorial.window.notes: 'Compile e execute a aplicação. Verifique se a janela abre e fecha normalmente e se é possível movê-la e redimensioná-la. O conteúdo ainda não está definido, pois nenhum comando de renderização foi enviado. Feche a janela antes de continuar.'
tutorial.window.title: 'Criação da janela'
ui.action.copy: 'Copiar'
@@ -525,7 +493,7 @@ ui.api.noNamespaceTypes: 'Nenhum tipo neste namespace.'
ui.api.noTypes: 'Nenhum tipo correspondente.'
ui.api.types: 'Tipos'
ui.content.reference: 'Referência'
-ui.content.source: 'Código-fonte'
+ui.content.examples: 'Exemplos de código'
ui.content.tutorial: 'Tutorial'
ui.contents.close: 'Fechar sumário'
ui.contents.open: 'Abrir sumário'
@@ -562,7 +530,6 @@ ui.reference.exceptions: 'Exceções'
ui.reference.extensionMethods: 'Métodos de extensão'
ui.reference.fields: 'Campos'
ui.reference.implementations: 'Implementações explícitas de interface'
-ui.reference.implements: 'Implementa'
ui.reference.inheritance: 'Herança'
ui.reference.inheritedMembers: 'Membros herdados'
ui.reference.interfaces: 'Interfaces'
@@ -575,8 +542,8 @@ ui.reference.parameters: 'Parâmetros'
ui.reference.properties: 'Propriedades'
ui.reference.related: 'Consulte também'
ui.reference.relationships: 'Herança e metadados'
-ui.reference.remarks: 'Comentários'
-ui.reference.returns: 'Retornos'
+ui.reference.remarks: 'Observações'
+ui.reference.returns: 'Retorno'
ui.reference.structs: 'Estruturas'
ui.reference.typeParameters: 'Parâmetros de tipo'
ui.reference.value: 'Valor'
diff --git a/documents/locales/pt-BR/translation.md b/documents/locales/pt-BR/translation.md
index 8d55ed34..e8c6cb44 100644
--- a/documents/locales/pt-BR/translation.md
+++ b/documents/locales/pt-BR/translation.md
@@ -6,7 +6,7 @@ O [dicionário de recursos em inglês](../en-US/strings.yml) é a única fonte d
Navegação, ordem dos capítulos, âncoras, links, formatação, código e imagens são mantidos fora de `locales/` e compartilhados entre idiomas. Não adicione artigos, TOC, templates, scripts ou configurações neste diretório.
-Altere apenas os valores da `strings.yml` deste idioma. O conjunto de chaves deve corresponder exatamente ao inglês. Não adicione, remova ou renomeie chaves por conta própria, mesmo que os textos pareçam iguais ou ainda não tenham aparecido na interface. Se encontrar um problema no original, informe a chave e o problema aos responsáveis pelo projeto. Corrija primeiro a fonte inglesa e as páginas compartilhadas; depois, atualize as traduções.
+Altere apenas os valores do arquivo `strings.yml` deste idioma. O conjunto de chaves deve corresponder exatamente ao inglês. Não adicione, remova ou renomeie chaves por conta própria, mesmo que os textos pareçam iguais ou ainda não tenham aparecido na interface. Se encontrar um problema no original, informe a chave e o problema aos responsáveis pelo projeto. Corrija primeiro a fonte inglesa e as páginas compartilhadas; depois, atualize as traduções.
## Estilo e contexto
@@ -38,7 +38,7 @@ Preserve estas distinções:
- Gravar comandos, enviá-los, executá-los na GPU e concluí-los são etapas distintas.
- Uso de recursos, residência de memória ou intenção de acesso da CPU, layout de textura e formato de pixel são conceitos distintos.
-- A propriedade indica a responsabilidade de liberar um recurso. Um handle não mantém o recurso vivo por si só; o envio de comandos também não transfere a propriedade.
+- A propriedade indica a responsabilidade de liberar um recurso. Um identificador não mantém o recurso vivo por si só; o envio de comandos também não transfere a propriedade.
- A conclusão na GPU nem sempre significa que os dados de leitura temporários já foram copiados para o destino de CPU da aplicação. Preserve as instruções sobre aguardar a fila responsável.
- Um drawable é a textura de saída do quadro atual, não necessariamente uma imagem da cadeia de troca. Distinga as visualizações de recursos dos controles de interface.
@@ -61,25 +61,28 @@ Este idioma já está registrado. O dicionário completo fica disponível após
Todos os idiomas compartilham os caminhos das páginas. `?lang=pt-BR` seleciona português brasileiro; a troca de idioma mantém o caminho e a âncora. Sem uma escolha explícita, são usadas, nesta ordem, a escolha manual salva, as preferências do navegador e o inglês. Se esta tradução ainda não estiver publicada, ou se o carregamento ou a validação dos recursos da página falhar, a página fica em inglês, sem misturar idiomas frase a frase. A lista de idiomas é ordenada por código.
-Antes de entregar, confira as chaves e os marcadores. Revise a página inicial, a entrada de Learn, o tutorial do triângulo, os conceitos, os exemplos e a interface de API no desktop e com 320 pixels de largura. Leia o tutorial como iniciante e confira terminologia, botões, busca, cópia de código, links de API e a posição da seção após trocar de idioma. Identificadores, declarações e código continuam compartilhados; traduza apenas os textos fornecidos pelo dicionário. Mantenha dicionários de teste e arquivos temporários fora do repositório e não entregue traduções com texto de preenchimento.
+Antes de entregar, confira as chaves e os marcadores. Revise a página inicial, a seção Aprender, o tutorial do triângulo, os conceitos, os exemplos e a interface da API no computador e com 320 pixels de largura. Leia o tutorial como iniciante e confira terminologia, botões, busca, cópia de código, links de API e a posição da seção após trocar de idioma. Identificadores, declarações e código continuam compartilhados; traduza apenas os textos fornecidos pelo dicionário. Mantenha dicionários de teste e arquivos temporários fora do repositório e não entregue traduções com texto de preenchimento.
## Terminologia
-| Termo em inglês | Forma adotada |
-| ---------------- | ----------------------------------------------------------------------------------------------------------- |
-| API / GPU / RHI | Preservar as siglas e explicá-las conforme o original |
-| barrier | barreira |
-| buffer | buffer; preservar `Buffer` |
-| command buffer | buffer de comandos |
-| command queue | fila de comandos |
-| drawable | textura de saída do quadro atual; preservar `Drawable`, sem presumir que seja uma imagem da cadeia de troca |
-| graphics context | contexto gráfico |
-| pipeline | pipeline |
-| readback | leitura de dados da GPU |
-| render pass | passagem de renderização |
-| resource | recurso |
-| shader | shader |
-| swap chain | cadeia de troca |
-| texture | textura |
-| timeline | linha do tempo |
-| upload | envio de dados à GPU |
+| Termo em inglês | Forma adotada |
+| ------------------- | ----------------------------------------------------------------------------------------------------------- |
+| API / GPU / RHI | Preservar as siglas e explicá-las conforme o original |
+| barrier | barreira |
+| buffer | buffer; preservar `Buffer` |
+| command buffer | buffer de comandos |
+| command queue | fila de comandos |
+| command recording | gravação de comandos; não alternar com registro de comandos |
+| drawable | textura de saída do quadro atual; preservar `Drawable`, sem presumir que seja uma imagem da cadeia de troca |
+| graphics context | contexto gráfico |
+| graphics API | API gráfica; DirectX 12, Metal 4 ou Vulkan 1.4 |
+| API implementation | implementação da API gráfica; para diferenças técnicas entre implementações |
+| pipeline | pipeline |
+| readback / download | download ou leitura de dados da GPU |
+| render pass | passagem de renderização |
+| resource | recurso |
+| shader | shader |
+| swap chain | cadeia de troca |
+| texture | textura |
+| timeline | linha do tempo |
+| upload | upload de dados para a GPU; distinto do envio de comandos à fila |
diff --git a/documents/locales/ru-RU/strings.yml b/documents/locales/ru-RU/strings.yml
index 9ccc4f3b..88e725ab 100644
--- a/documents/locales/ru-RU/strings.yml
+++ b/documents/locales/ru-RU/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: '{graphicsContext} связывает приложение с устройством GPU через определённый бэкенд и предоставляет его графическую, вычислительную и передающую очереди. Совместно используемые ресурсы должны принадлежать одному контексту: буферы, текстуры, шейдеры, конвейеры и их дескрипторы нельзя привязывать между разными контекстами.'
+concepts.execution.context.description: '{graphicsContext} связывает приложение с устройством GPU через выбранный графический API и предоставляет очереди графики, вычислений и передачи данных. Совместно используемые ресурсы должны принадлежать одному контексту: буферы, текстуры, шейдеры, конвейеры и их дескрипторы нельзя привязывать между разными контекстами.'
concepts.execution.context.details: '{capabilities} сообщает имя устройства и поддерживаемые возможности. Перед созданием ресурсов для трассировки лучей или меш-шейдинга проверяйте соответственно {rayTracingSupported} и {meshShadingSupported}. Такие проверки при инициализации показаны в примерах {link} и {detail}.'
concepts.execution.context.details.detail: 'меш-шейдинга'
concepts.execution.context.details.link: трассировки лучей
@@ -11,7 +11,7 @@ concepts.execution.ownership.guidance: 'Во время рендеринга о
concepts.execution.ownership.guidance.link: Управление ресурсами
concepts.execution.ownership.table.applicationResources.object: Ресурсы, созданные приложением
concepts.execution.ownership.table.applicationResources.ownership: Приложение освобождает их после последнего использования на GPU.
-concepts.execution.ownership.table.commandBuffers.object: 'Заимствованные буферы команд'
+concepts.execution.ownership.table.commandBuffers.object: 'Заимствованные командные буферы'
concepts.execution.ownership.table.commandBuffers.ownership: Очередь управляет ими и повторно использует их.
concepts.execution.ownership.table.headings.object: Объект
concepts.execution.ownership.table.headings.ownership: 'Ответственность за освобождение'
@@ -26,7 +26,7 @@ concepts.execution.pipelines.guidance.detail: 'вычислительном пр
concepts.execution.pipelines.guidance.link: 'обработчике рендеринга треугольника'
concepts.execution.pipelines.title: 'Состояние конвейера'
concepts.execution.queues.description: '{graphicsQueue} обычно подходит для кадра, объединяющего рисование, вычисления и копирование. Размещение зависимых операций в одной очереди упрощает их упорядочивание.'
-concepts.execution.queues.details: 'Отдельные очереди позволяют независимо отправлять разные задачи, но не обязательно соответствуют независимым аппаратным блокам. Дополнительные очереди полезны, если задачи могут выиграть от перекрытия выполнения. Когда одна очередь использует данные другой, между их отправками нужна явная зависимость.'
+concepts.execution.queues.details: 'Дополнительные очереди могут помочь совместить выполнение независимых задач, хотя каждой очереди не обязательно соответствует отдельный аппаратный блок. Если одна очередь использует данные, созданные другой, задайте явную зависимость между отправками.'
concepts.execution.queues.guidance: 'Даже в одной очереди зависимым операциям могут понадобиться барьеры или переходы состояния текстур, чтобы последующие обращения видели результаты предыдущих записей. Эти зависимости по памяти отличаются от порядка отправки команд. Как их задавать, описано в статье «{link}».'
concepts.execution.queues.guidance.link: Синхронизация
concepts.execution.queues.table.computeQueue.workToRecord: 'Запуск вычислений и совместимые операции передачи данных, без графических проходов рендеринга.'
@@ -35,24 +35,22 @@ concepts.execution.queues.table.headings.queue: Очередь
concepts.execution.queues.table.headings.workToRecord: 'Поддерживаемые операции'
concepts.execution.queues.table.transferQueue.workToRecord: 'Загрузка, считывание и копирование без рисования и вычислительных запусков.'
concepts.execution.queues.title: 'Выбор очереди'
-concepts.execution.recording.context: 'Очередь возвращает завершённые командные буферы для повторного использования. Для каждой записи получите буфер через {queueCommandBuffer}, записывайте его только из одного потока одновременно и отправьте один раз. После отправки оставьте управление очереди: не изменяйте буфер, не отправляйте его повторно и не освобождайте самостоятельно.'
+concepts.execution.recording.context: 'Очередь повторно использует командные буферы после завершения работы. Для каждой записи получите буфер через {queueCommandBuffer}, записывайте команды из одного потока за раз и отправьте буфер только однажды. После отправки оставьте управление очереди: не изменяйте буфер, не отправляйте его повторно и не освобождайте самостоятельно.'
concepts.execution.recording.description: '{queueCommandBuffer} возвращает {commandBuffer}, уже открытый для записи. Запишите операции и зависимости, затем один раз вызовите {submit}. Вызов завершает запись и возвращает {timelineValue}, обозначающий точку завершения в этой очереди.'
concepts.execution.recording.details: 'После записи кадра в {commandBuffer} учебный пример отправляет команды и ожидает завершения:'
concepts.execution.recording.guidance: 'Запись формирует последовательность команд, а {submit} планирует её выполнение. Последующий вызов {wait} блокирует поток CPU до завершения отправленной работы. Поэтому цикл кадров в уроке легко проследить: каждый кадр заканчивается до начала следующего.'
concepts.execution.recording.title: 'Запись и отправка команд'
concepts.execution.title: Модель выполнения
-concepts.platforms.description: 'Выводом управляет приложение или элемент интерфейса. От этого зависит, кто получает выходную текстуру кадра, записывает и отправляет команды и выводит результат. Эта выходная текстура называется drawable.'
-concepts.platforms.frame.context: 'Записывайте привязку конвейера и команды рисования внутри прохода и завершайте его до возврата из обработчика. Элемент управления сам отправит команды и выведет результат. Обработчик не должен отправлять командный буфер или освобождать любой из двух предоставленных объектов. Если он меняет состояние выходной текстуры, перед возвратом нужно восстановить {colorAttachment}, чтобы элемент управления выполнил заключительный переход.'
+concepts.platforms.description: 'Выводом управляет приложение или элемент управления рендерингом. От этого зависит, кто получает выходную текстуру кадра, записывает и отправляет команды и выводит результат. Эта выходная текстура называется drawable.'
+concepts.platforms.frame.context: 'Записывайте привязку конвейера и команды рисования внутри прохода и завершайте его до возврата из обработчика. Обработчик не должен отправлять командный буфер и не должен освобождать ни один из двух переданных объектов. Если он меняет состояние выходной текстуры, перед возвратом нужно восстановить {colorAttachment}, чтобы элемент управления выполнил заключительный переход.'
concepts.platforms.frame.description: 'Элементы реализуют {iZenithView}. Приложение назначает {graphicsContext}, обновляет сцену в {updateRequested} и записывает команды в {renderRequested}, используя переданный {renderEventArgs}.'
concepts.platforms.frame.details: 'Для каждого кадра элемент управления получает выходную текстуру и командный буфер, переводит текстуру в {colorAttachment} и вызывает обработчики обновления и рендеринга. Затем он отправляет записанные команды и выводит изображение средствами выбранного UI-фреймворка.'
concepts.platforms.frame.guidance: 'Добавьте {usingZenithNET} в файл. Для инициализированного {iZenithView} с именем {view} и назначенным графическим контекстом зарегистрируйте обработчик, заполняющий выходную текстуру цветом:'
concepts.platforms.frame.notes: 'Первый переход использует {undefined}, разрешая отбросить прежнее содержимое изображения. Поэтому каждый кадр должен заново заполнять или отрисовывать всё изображение. Накопленные или кешированные результаты храните в текстуре приложения, а затем рисуйте её в выходную текстуру элемента управления.'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} предоставляет цветовой формат, используемый по умолчанию в этих интеграциях.'
concepts.platforms.frame.title: 'Рендеринг в элементах интерфейса'
concepts.platforms.integration.context: 'WinForms, WPF и Windows-интеграция WinUI работают под Windows. Для MAUI установите рабочую нагрузку целевой платформы и зарегистрируйте обработчик элемента управления через {useZenithView}, как показано в {extensionsCs}.'
concepts.platforms.integration.description: 'Интерфейс событий общий, но механизм вывода зависит от фреймворка:'
-concepts.platforms.integration.details: 'Реализации различаются тем, как изображение GPU попадает в интерфейс. Считывание в растровое изображение копирует пиксели в память CPU перед показом. Совместное использование текстуры исключает эту копию на CPU, но всё ещё может требовать копирования на GPU и синхронизации. При выборе интеграции учитывайте этот путь вывода наряду с общим событием {renderRequested}.'
-concepts.platforms.integration.guidance: 'Добавьте через NuGet пакет интеграции для вашего UI-фреймворка. Для Avalonia используйте {avaloniaPackage}.'
+concepts.platforms.integration.details: 'Способ вывода изображения GPU зависит от выбранной интеграции. При считывании в растровое изображение пиксели перед показом копируются в память CPU. Совместное использование текстуры позволяет обойтись без этой копии, но всё ещё может требовать копирования на GPU и синхронизации. Учитывайте способ вывода наряду с общим событием {renderRequested}.'
concepts.platforms.integration.table.avalonia.integration: Avalonia
concepts.platforms.integration.table.avalonia.presentation: 'Рисует в текстуру и считывает пиксели в {writeableBitmap}. Реализация: {zenithViewCs} и {surfaceCs}.'
concepts.platforms.integration.table.headings.integration: Интеграция
@@ -60,14 +58,14 @@ concepts.platforms.integration.table.headings.presentation: 'Механизм в
concepts.platforms.integration.table.maui.integration: .NET MAUI
concepts.platforms.integration.table.maui.presentation: Использует нативные поверхности в Android, iOS и Mac Catalyst, а в Windows — композицию через разделяемые текстуры. См. {link}.
concepts.platforms.integration.table.maui.presentation.link: реализации для платформ
-concepts.platforms.integration.table.uno.integration: Вариант Uno
+concepts.platforms.integration.table.uno.integration: Uno Platform
concepts.platforms.integration.table.uno.presentation: Считывает пиксели в {writeableBitmap}. См. {zenithViewUnoCs}.
concepts.platforms.integration.table.winForms.integration: WinForms
concepts.platforms.integration.table.winForms.presentation: Создаёт цепочку обмена Zenith.NET для дескриптора {hWND} элемента управления. См. {zenithViewCs}.
concepts.platforms.integration.table.winUI.integration: WinUI в Windows
-concepts.platforms.integration.table.winUI.presentation: 'Рисует в импортированную общую текстуру Direct3D 11, затем копирует результат в композиционную цепочку обмена, связанную с {swapChainPanel}. Реализация: {zenithViewWinUICs}.'
+concepts.platforms.integration.table.winUI.presentation: 'Рисует в импортированную разделяемую текстуру Direct3D 11, затем копирует результат в композиционную цепочку обмена, связанную с {swapChainPanel}. Реализация: {zenithViewWinUICs}.'
concepts.platforms.integration.table.wpf.integration: WPF
-concepts.platforms.integration.table.wpf.presentation: 'Импортирует общую текстуру Direct3D 11 и через взаимодействие с Direct3D копирует её в поверхность, отображаемую {d3DImage}. Реализация: {surfaceCs}.'
+concepts.platforms.integration.table.wpf.presentation: 'Импортирует разделяемую текстуру Direct3D 11 и через взаимодействие с Direct3D копирует её в поверхность, отображаемую {d3DImage}. Реализация: {surfaceCs}.'
concepts.platforms.integration.title: 'Фреймворк и вывод изображения'
concepts.platforms.lifecycle.context: 'При создании соответствующих вложений используйте {descWidth}, {descHeight}, {descFormat} и {descSampleCount} выходной текстуры, переданной событием рендеринга. Эта текстура задаёт реальные размеры цели вывода; их не следует вычислять по размеру элемента интерфейса или масштабу экрана.'
concepts.platforms.lifecycle.description: 'Цепочка обмена использует ширину и высоту кадрового буфера в пикселях. При масштабировании экрана они могут отличаться от логических размеров окна. Отложите рендеринг и изменение размера цепочки, пока хотя бы один размер равен нулю. Получайте {swapChainDrawable} для каждого кадра: цепочка обмена владеет этой текстурой и может заменить её после вывода или изменения размера.'
@@ -76,16 +74,16 @@ concepts.platforms.lifecycle.guidance: 'Если размеры принадле
concepts.platforms.lifecycle.guidance.link: 'примере вращающегося куба'
concepts.platforms.lifecycle.title: 'Размеры и время жизни цепочки обмена'
concepts.platforms.ownership.description: 'Приложение владеет назначенным контекстом и своими ресурсами рендеринга, а элемент управления — ресурсами вывода. При изменении {graphicsContext} представления планировщик пересоздаёт ресурсы элемента управления для нового контекста. Приложение также должно пересоздать для этого контекста свои конвейеры, буферы и текстуры.'
-concepts.platforms.ownership.details: 'Перед заменой ресурсов рендеринга остановите обработку кадров представления и дождитесь использующей их работы GPU. Только после этого освобождайте старые ресурсы или контекст. При удалении представления приложение по-прежнему отвечает за освобождение назначенного контекста.'
+concepts.platforms.ownership.details: 'Перед заменой ресурсов рендеринга остановите цикл обработки кадров представления и дождитесь использующей их работы GPU. Затем освободите старые ресурсы. Освобождайте контекст только после того, как каждое представление освободит свои ресурсы вывода, относящиеся к этому контексту, и будут освобождены все ресурсы приложения, созданные из него.'
concepts.platforms.ownership.guidance: 'Общий {frameSchedulerCs} выполняет обработчики кадров через диспетчер UI представления. Ограничивайте их работу обновлением сцены и записью команд: длительные вычисления на CPU здесь задерживают и отклик интерфейса.'
-concepts.platforms.ownership.title: 'Ресурсы приложения и элемента интерфейса'
+concepts.platforms.ownership.title: 'Владение ресурсами приложения и элемента управления'
concepts.platforms.surface.description: 'В {link} Silk.NET создаёт окно и обрабатывает события. Zenith.NET получает нативные дескрипторы окна и его размеры через описание {surface}, по которому создаёт {swapChain}. За само окно операционной системы по-прежнему отвечает приложение.'
concepts.platforms.surface.description.link: 'уроке с треугольником'
-concepts.platforms.surface.details: 'Дескрипторы поверхности должны соответствовать бэкенду:'
+concepts.platforms.surface.details: 'Дескрипторы поверхности зависят от графического API и оконной системы. Распространённые сочетания:'
concepts.platforms.surface.guidance: 'Общая оболочка примеров в {appCs} поддерживает Windows, macOS и X11. Под Linux её окно предоставляет дескрипторы Xlib, поэтому в сеансе Wayland для запуска нужен XWayland. Приложение с нативным Wayland передаёт дескрипторы дисплея и поверхности через {surfaceWayland}.'
concepts.platforms.surface.table.android.backend: Vulkan в Android.
concepts.platforms.surface.table.apple.backend: Metal на платформах Apple.
-concepts.platforms.surface.table.headings.backend: 'Бэкенд и платформа'
+concepts.platforms.surface.table.headings.backend: 'Графический API и платформа'
concepts.platforms.surface.table.headings.factory: Фабрика поверхности
concepts.platforms.surface.table.headings.handles: Дескрипторы, предоставляемые хостом
concepts.platforms.surface.table.wayland.backend: Vulkan с нативным хостом Wayland.
@@ -97,7 +95,7 @@ concepts.platforms.surface.title: 'Нативные поверхности вы
concepts.platforms.title: Интеграция с платформами
concepts.resources.allocation.context: 'Размещённые в куче ресурсы зависят от её памяти в течение всего своего времени жизни. После последнего использования на GPU освободите сначала ресурсы, затем кучу.'
concepts.resources.allocation.description: 'Используйте {heap}, если приложение должно самостоятельно управлять выделением памяти. Ресурсы размещаются в куче по явно заданным смещениям в байтах; приложение выбирает эти смещения и учитывает занятые области.'
-concepts.resources.allocation.details: 'Для каждого ресурса вызовите {contextGetSizeAndAlignment} с тем описанием буфера или текстуры, которое будет использовано при создании. Зарезервируйте возвращённый размер по смещению, кратному указанному выравниванию. Вся область должна находиться в пределах кучи и не пересекать другую ещё действующую область. Размер текстуры может включать дополнительные промежутки, зависящие от бэкенда, поэтому вычислить его только по числу пикселей и байтам на пиксель нельзя.'
+concepts.resources.allocation.details: 'Для каждого ресурса вызовите {contextGetSizeAndAlignment} с тем описанием буфера или текстуры, которое будет использовано при создании. Выделите область возвращённого размера по смещению, кратному указанному выравниванию. Эта область должна помещаться в куче и не пересекаться с другим ещё используемым выделением. Размер текстуры может включать дополнительные байты заполнения, поэтому вычислить его только по числу пикселей и байтам на пиксель нельзя.'
concepts.resources.allocation.guidance: 'Резидентность буфера, размещённого в куче, должна совпадать с резидентностью этой кучи. Для текстур используйте кучу, предназначенную только для GPU.'
concepts.resources.allocation.title: 'Размещение в кучах памяти'
concepts.resources.bufferUsages.table.constant.role: Параметры шейдера, считываемые через привязку буфера констант.
@@ -108,12 +106,12 @@ concepts.resources.bufferUsages.table.indirect.role: 'Аргументы, счи
concepts.resources.bufferUsages.table.none.role: 'Флаги назначения буфера не объявлены.'
concepts.resources.bufferUsages.table.storageReadOnly.role: 'Данные буфера, доступные через привязку шейдера только для чтения.'
concepts.resources.bufferUsages.table.storageReadWrite.role: 'Данные буфера, доступные через привязку шейдера для чтения и записи.'
-concepts.resources.bufferUsages.table.transferDst.role: 'Память назначения для копирования на GPU.'
-concepts.resources.bufferUsages.table.transferSrc.role: 'Исходные данные для копирования на GPU.'
+concepts.resources.bufferUsages.table.transferDst.role: 'Память буфера, в которую GPU копирует данные.'
+concepts.resources.bufferUsages.table.transferSrc.role: 'Исходные данные буфера для копирования средствами GPU.'
concepts.resources.bufferUsages.table.vertex.role: 'Вершинные атрибуты, считываемые для рисования.'
concepts.resources.bufferUsages.title: Назначения буфера
concepts.resources.description: 'Описание ресурса задаёт допустимые способы использования его памяти. Например, текстуре, которая служит целью рендеринга, читается шейдером и копируется на CPU, нужны флаги назначения для всех трёх операций. Размещение памяти определяет доступ CPU, а синхронизация и управление временем жизни — когда можно обращаться к данным и освобождать память.'
-concepts.resources.memory.context: 'Для доступных CPU буферов {map} возвращает адрес, по которому можно читать или записывать данные. Ни отображение памяти, ни {unmap} не дожидаются GPU. Перед чтением результата приложение должно дождаться его записи на GPU, а перед изменением тех же байтов — всех ещё выполняющихся обращений GPU к ним.'
+concepts.resources.memory.context: 'Для буферов, доступных CPU, {map} возвращает адрес, по которому можно читать или записывать данные. Ни отображение памяти, ни {unmap} не ждут завершения работы GPU. Перед чтением результата приложение должно дождаться его записи на GPU, а перед изменением тех же байтов — всех ещё выполняющихся обращений GPU к ним.'
concepts.resources.memory.description: 'Поле {residency} в {bufferDesc} задаёт предполагаемый доступ CPU к памяти:'
concepts.resources.memory.details: 'Резидентность выражает требования к доступу CPU, в том числе на системах с общей физической памятью CPU и GPU. В примере треугольника {cpuWriteOnly} позволяет напрямую заполнить небольшой вершинный буфер. Для более объёмной статической геометрии может быть предпочтительнее загрузка в память, предназначенную только для GPU.'
concepts.resources.memory.guidance: 'Текстуры, создаваемые непосредственно через контекст, используют память GPU. Поэтому в {textureDesc} нет поля резидентности: приложение обменивается данными с памятью CPU через загрузку и считывание.'
@@ -124,10 +122,10 @@ concepts.resources.memory.table.cpuWriteOnly.typicalRole: 'Данные, пре
concepts.resources.memory.table.gpuOnly.cPUAccess: 'Не предусмотрен'
concepts.resources.memory.table.gpuOnly.typicalRole: 'Статическая геометрия и рабочие данные GPU'
concepts.resources.memory.table.headings.cPUAccess: 'Предусмотренный доступ CPU'
-concepts.resources.memory.table.headings.residency: 'Режим доступа к памяти'
+concepts.resources.memory.table.headings.residency: 'Резидентность'
concepts.resources.memory.table.headings.typicalRole: Типичная роль
concepts.resources.memory.title: 'Доступ CPU и размещение памяти'
-concepts.resources.textureUsages.description: 'Флаги передачи указывают, служит ли ресурс источником или приёмником при копировании на GPU. Прямой доступ CPU к его памяти определяется отдельно, при выборе размещения памяти.'
+concepts.resources.textureUsages.description: 'Флаги передачи указывают, служит ли ресурс источником или приёмником при копировании средствами GPU. Прямой доступ CPU к его памяти определяется отдельно, при выборе размещения памяти.'
concepts.resources.textureUsages.details: 'Флаги назначения объявляют допустимые способы использования текстуры. Переход между ними требует соблюдения правил, описанных в разделе «{link}». Устройство также должно поддерживать выбранные операции для указанного формата текстуры.'
concepts.resources.textureUsages.details.link: 'состояния доступа и синхронизация'
concepts.resources.textureUsages.table.colorAttachment.role: 'Цветовое вложение в проходе рендеринга.'
@@ -137,36 +135,36 @@ concepts.resources.textureUsages.table.headings.usage: Назначение
concepts.resources.textureUsages.table.none.role: 'Флаги назначения текстуры не объявлены.'
concepts.resources.textureUsages.table.sampled.role: 'Данные текстуры, считываемые через привязку сэмплируемой текстуры.'
concepts.resources.textureUsages.table.storage.role: 'Данные текстуры, доступные через привязку текстуры хранения для чтения или записи шейдером.'
-concepts.resources.textureUsages.table.transferDst.role: 'Память изображения назначения для копирования на GPU.'
-concepts.resources.textureUsages.table.transferSrc.role: 'Данные исходного изображения для копирования на GPU.'
+concepts.resources.textureUsages.table.transferDst.role: 'Память изображения, в которую GPU копирует данные.'
+concepts.resources.textureUsages.table.transferSrc.role: 'Исходные данные изображения для копирования средствами GPU.'
concepts.resources.textureUsages.title: Назначения текстуры
concepts.resources.title: Управление ресурсами
-concepts.resources.transfers.context: 'При считывании данные GPU сначала копируются во внутреннюю промежуточную память. Затем библиотека переносит их в указанную память CPU, когда возвращает завершённый командный буфер для повторного использования. Вызов {wait} для значения отправки, содержащей считывание, завершает оба шага. До возврата из этого вызова память назначения должна оставаться выделенной, а управляемая память — закреплённой.'
+concepts.resources.transfers.context: 'При считывании данные GPU сначала копируются во внутреннюю память для считывания. Затем библиотека переносит их в указанную память CPU, когда забирает завершённый командный буфер для повторного использования. Вызов {wait} для значения отправки, содержащей считывание, завершает оба шага. До возврата из этого вызова память назначения должна оставаться выделенной, а управляемая память — закреплённой.'
concepts.resources.transfers.description: 'Загрузка копирует данные CPU в ресурс GPU, а считывание — данные ресурса в память CPU. Методы буферов и текстур завершают передачу до возврата управления:'
concepts.resources.transfers.details: 'Перед вызовом этих методов устраните конфликтующие обращения из других очередей. Внутреннее ожидание метода относится только к его собственной передаче и не создаёт зависимость от другой очереди. При прямом копировании через отображённую память ожидание конфликтующих обращений GPU полностью возлагается на вызывающий код.'
concepts.resources.transfers.guidance: 'Чтобы отправить передачу данных вместе с другой работой GPU, запишите её через {commandBufferUpload} или {commandBufferDownload}. Требования ко времени жизни исходной памяти при загрузке и памяти назначения при считывании различаются:'
concepts.resources.transfers.item: 'Во время вызова загрузки библиотека копирует исходные данные во временную промежуточную память. Позже GPU читает данные именно из неё, поэтому исходный указатель приложения нужен только до возврата из вызова.'
-concepts.resources.transfers.notes: 'При передаче текстур шаг строки — это расстояние в байтах между соседними строками данных CPU, а шаг среза — расстояние между соседними срезами по глубине. По этим значениям выполняется копирование между памятью CPU и хранилищем текстуры на GPU. Почему завершение GPU и запись в память назначения — разные этапы, объясняется в статье «{link}».'
-concepts.resources.transfers.notes.link: Синхронизация
-concepts.resources.transfers.table.bufferDownload.transfer: 'Для {cpuReadOnly} копирует непосредственно из отображённой памяти. В остальных случаях отправляет считывание в передающую очередь и дожидается его завершения.'
-concepts.resources.transfers.table.bufferUpload.transfer: 'Для {cpuWriteOnly} копирует непосредственно в отображённую память. В остальных случаях отправляет загрузку в передающую очередь и дожидается её завершения.'
+concepts.resources.transfers.layouts: 'Записанные операции передачи текстуры не включают переходы состояния. Для загрузки требуется {copyDst}, для считывания — {copySrc}. Перед копированием запишите переход в соответствующее состояние, а после него — в состояние, необходимое для следующего использования.'
+concepts.resources.transfers.notes: 'При передаче текстур шаг строки — это расстояние в байтах между соседними строками данных CPU, а шаг среза — расстояние между соседними срезами по глубине. По этим значениям выполняется копирование между памятью CPU и хранилищем текстуры на GPU.'
+concepts.resources.transfers.table.bufferDownload.transfer: 'Для {cpuReadOnly} копирует непосредственно из отображённой памяти. В остальных случаях отправляет считывание в очередь передачи данных и дожидается его завершения.'
+concepts.resources.transfers.table.bufferUpload.transfer: 'Для {cpuWriteOnly} копирует непосредственно в отображённую память. В остальных случаях отправляет загрузку в очередь передачи данных и дожидается её завершения.'
concepts.resources.transfers.table.headings.method: Метод
-concepts.resources.transfers.table.headings.transfer: 'Порядок передачи'
+concepts.resources.transfers.table.headings.transfer: 'Как выполняется передача'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: 'Отправляет копирование и переходы состояния текстуры в графическую очередь, затем ожидает завершения. Выбранный подресурс остаётся в запрошенном конечном состоянии.'
-concepts.resources.transfers.title: 'Немедленная и записываемая передача'
+concepts.resources.transfers.title: 'Непосредственная передача и передача через командный буфер'
concepts.resources.usages.description: '{bufferUsages} и {textureUsages} — флаговые перечисления, объявляющие предполагаемые роли ресурса. Они задаются в полях {bufferDescUsages} и {textureDescUsages} соответственно. Если у ресурса несколько ролей, члены флагового перечисления можно объединить с помощью {value}.'
concepts.resources.usages.title: 'Назначения ресурсов'
-concepts.resources.views.description: '{bufferView} описывает область буфера и интерпретацию её данных. {textureView} выбирает диапазон подресурсов, совместимые тип и формат текстуры. Оба представления ссылаются на существующую память с назначениями, объявленными при её создании. Диапазоны представлений описывают доступ, но не обеспечивают одинаковую проверку границ в шейдерах на всех бэкендах.'
+concepts.resources.views.description: '{bufferView} описывает область буфера и интерпретацию её данных. {textureView} выбирает диапазон подресурсов, совместимые тип и формат текстуры. Оба представления ссылаются на существующую память с назначениями, объявленными при её создании. Диапазоны представлений описывают доступ, но не гарантируют единообразной проверки границ в шейдерах.'
concepts.resources.views.details: 'Собственный дескриптор ресурса предоставляет его представление по умолчанию. Для другой области или совместимого способа интерпретации создайте отдельное представление. Сохраняйте и представление, и исходный ресурс до завершения их использования на GPU: дескриптор сам по себе не удерживает ни один из объектов. При замене любого из них обновите константы, содержащие прежний {link}.'
concepts.resources.views.details.link: 'дескриптор ресурса'
concepts.resources.views.title: 'Представления и исходные ресурсы'
concepts.shaders.binding.context: 'В вычислительном примере {inputTextureSampledHandle} присваивается {input}, а {outputTextureStorageHandle} — {output}. В Slang параметр типа {descriptorHandle} определяет доступ шейдера к ресурсу:'
concepts.shaders.binding.description: '{setConstantBuffer} выбирает существующий буфер и смещение в байтах, с которого текущий конвейер читает константы. Загрузите параметры в эту память до обращения шейдера. Если ранее отправленная работа GPU ещё читает те же байты, дождитесь её завершения перед обновлением.'
concepts.shaders.binding.details: 'Подготовьте командный буфер, вычислительный конвейер, заполненный константный буфер и число групп потоков. Затем запишите запуск вычислений в следующем порядке. Сначала выберите конвейер, поскольку привязка константного буфера относится именно к нему:'
-concepts.shaders.binding.guidance: 'Здесь {commandBuffer} записывает запуск {computePipeline} с параметрами из {constantBuffer}. Буферу нужно назначение {bufferUsagesConstant}; смещение 0 выбирает его начало. Если в буфере несколько записей констант, начальное смещение каждой также должно удовлетворять выравниванию привязки, требуемому бэкендом. Это отдельное условие, не зависящее от размещения полей внутри записи.'
-concepts.shaders.binding.notes: '{resourceHandle} содержит два 32-битных поля, интерпретация которых зависит от бэкенда. Их значения действительны только в контексте, где создан ресурс.'
-concepts.shaders.binding.reference: 'Сохраняйте ресурс и представление, из которого получен дескриптор, до завершения последнего обращения шейдера. При замене обновите константы со старым дескриптором. Правила владения изложены в статье «{link}».'
+concepts.shaders.binding.guidance: 'Константному буферу нужно назначение {bufferUsagesConstant}. Если в буфере несколько записей констант, начальное смещение каждой должно соответствовать требуемому выравниванию привязки. Это условие не зависит от размещения полей внутри записи.'
+concepts.shaders.binding.notes: '{resourceHandle} содержит два 32-битных поля, интерпретация которых зависит от графического API. Их значения действительны только в контексте, где создан ресурс.'
+concepts.shaders.binding.reference: 'Сохраняйте ресурс и представление, из которого получен дескриптор, до завершения последнего обращения шейдера. При замене текстуры или представления обновите константы со старым дескриптором. Правила владения изложены в статье «{link}».'
concepts.shaders.binding.reference.link: Управление ресурсами
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: 'Чтение структурированных элементов шейдерного типа {t}'
concepts.shaders.binding.table.bufferStorageReadWriteHandle.access: 'Чтение и запись структурированных элементов шейдерного типа {t}'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: 'Состояние выб
concepts.shaders.binding.table.textureSampledHandle.access: 'Чтение текстур'
concepts.shaders.binding.table.textureStorageHandle.access: 'Чтение и запись текстур хранения'
concepts.shaders.binding.title: 'Буферы констант и дескрипторы ресурсов'
-concepts.shaders.compilation.description: '{zenithCompiler} компилирует именованную точку входа Slang в {shaderDesc}. {graphicsApi} контекста определяет результат: DXIL для DirectX 12, библиотеку Metal для Metal или SPIR-V для Vulkan.'
+concepts.shaders.compilation.description: '{zenithCompiler} компилирует точку входа Slang и возвращает {shaderDesc}. Свойство {graphicsApi} контекста определяет формат результата: {dxil} для DirectX 12, {metallib} для Metal или {spirv} для Vulkan.'
concepts.shaders.compilation.details: 'Используя уже созданный графический контекст {context}, скомпилируйте шейдер треугольника из копии рядом с исполняемым файлом:'
concepts.shaders.compilation.guidance: 'Имя точки входа {vSMain} должно совпадать с её объявлением в файле шейдера. Компилируйте шейдеры и создавайте конвейеры при инициализации, а во время рендеринга используйте готовые конвейеры повторно. После создания конвейера объекты шейдеров можно освободить, как показано в {link}.'
concepts.shaders.compilation.guidance.link: 'учебном примере треугольника'
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: 'Для вершинного ввода {in
concepts.shaders.layout.details: 'Константные буферы содержат параметры шейдера, а структурированные — массивы типизированных элементов. Их раскладка определяется объявлениями Slang, а не {inputLayout}. Смещения полей C#, размеры элементов и выравнивающие промежутки должны соответствовать раскладке скомпилированного шейдера. Неуправляемый тип C# можно скопировать как последовательность байтов, но его размещение в памяти не обязательно соответствует раскладке шейдера: плотно упакованный {float3} в вершине может требовать другого выравнивания в буфере шейдера.'
concepts.shaders.layout.guidance: 'Параметры шейдера могут содержать дескрипторы ресурсов наряду с обычными значениями. Дескриптор указывает на уже существующую память, поэтому его копирование в константный буфер не копирует содержимое ресурса.'
concepts.shaders.layout.notes: 'Соответствующее объявление в {computeShaderSlang}:'
-concepts.shaders.layout.reference: 'Два размера занимают первые восемь байт, за ними следуют два дескриптора по восемь байт каждый. В примере C# под всю запись отведено 256 байт. Размер другой записи следует определять по её собственным полям, требуемой раскладке и выравниванию.'
+concepts.shaders.layout.reference: 'Поля C# занимают первые 24 байта: восемь под размеры и восемь под каждый из двух дескрипторов. Размер записи составляет 256 байт; остальные байты служат заполнением. Для другого блока параметров согласуйте смещения полей с раскладкой в шейдере. Если несколько записей размещены в одном буфере, добавьте между ними байты заполнения, чтобы начальное смещение каждой записи соответствовало требуемому выравниванию привязки.'
concepts.shaders.layout.title: 'Размещение данных'
concepts.shaders.matrices.description: 'Компилятор использует построчное хранение матриц: элементы каждой строки расположены подряд. В {link} три значения {matrix4x4} находятся по смещениям 0, 64 и 128 байт. Его {detail} применяет {mulVectorMatrix} в порядке модели, вида и проекции.'
concepts.shaders.matrices.description.detail: 'шейдер'
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: 'рендерере вращающе
concepts.shaders.matrices.details: 'Порядок хранения определяет размещение элементов матрицы в памяти; порядок умножения — преобразование. Используйте согласованные соглашения в C# и Slang.'
concepts.shaders.matrices.title: 'Соглашения о матрицах'
concepts.shaders.title: Данные шейдеров и привязка
-concepts.synchronization.backends.description: 'DirectX 12 и Vulkan кодируют переходы текстур как изменения состояния и доступа. В реализации {transition} для Metal в Zenith.NET нет эквивалентной операции. Вместо этого бэкенд Metal объединяет команды в графические и вычислительные кодировщики и вставляет барьеры видимости при завершении кодировщика. Для зависимых операций внутри одного кодировщика, например последовательных вычислительных запусков, нужны явные вызовы {barrier}.'
-concepts.synchronization.backends.details: 'В {link} начало графического прохода завершает вычислительный кодировщик и делает его результат видимым графическим командам. Два последовательных вычислительных запуска остаются в одном кодировщике, поэтому их зависимость требует барьера, даже если между ними записан переход состояния текстуры. Переносимая последовательность команд должна учитывать и зависимости обращений, и состояния текстур.'
+concepts.synchronization.backends.description: 'DirectX 12 и Vulkan кодируют переходы текстур как изменения состояния и доступа. В реализации {transition} для Metal в Zenith.NET нет эквивалентной операции. Вместо этого реализация для Metal объединяет команды в графические и вычислительные кодировщики и вставляет барьеры видимости при завершении кодировщика. Для зависимых операций внутри одного кодировщика, например последовательных вычислительных запусков, нужны явные вызовы {barrier}.'
+concepts.synchronization.backends.details: 'В {link} начало графического прохода завершает вычислительный кодировщик и делает его результат видимым графическим командам. Два последовательных вычислительных запуска остаются в одном кодировщике, поэтому их зависимость требует барьера, даже если между ними записан переход состояния текстуры.'
concepts.synchronization.backends.details.link: примере вычислений
-concepts.synchronization.backends.title: 'Поведение бэкендов'
+concepts.synchronization.backends.title: 'Синхронизация в разных графических API'
concepts.synchronization.barriers.context: 'Выбирайте стадии, которые охватывают нужные обращения и поддерживаются очередью. {barrierStagesAll} включает все поддерживаемые стадии. Если зависимость затрагивает лишь часть из них, можно указать более узкий набор.'
concepts.synchronization.barriers.description: 'Рассмотрим два запуска вычислений в одном командном буфере: первый записывает данные симуляции, второй их читает. Барьер между ними позволяет второму запуску увидеть результаты завершённых записей. Для буфера хранения он упорядочивает обращения без перехода состояния текстуры:'
concepts.synchronization.barriers.details: 'Первый аргумент указывает стадии, которые произвели данные, второй — стадии, которым они понадобятся. Вместе они описывают порядок выполнения и видимость памяти, необходимые между двумя запусками.'
-concepts.synchronization.barriers.guidance: 'Этот порядок используется в {link} между шагами симуляции. Каждый барьер следует за запуском, который производит данные, и предшествует запуску, который их использует.'
+concepts.synchronization.barriers.guidance: 'Этот порядок используется в {link} между шагами симуляции.'
concepts.synchronization.barriers.guidance.link: симуляции FluidTank
concepts.synchronization.barriers.title: 'Барьеры конвейера'
concepts.synchronization.dependencies.description: 'Для каждого ресурса определите обращения к одним и тем же данным. Если хотя бы одно из них записывает, сохраните необходимый порядок. Два чтения не конфликтуют, хотя требования к состоянию текстуры и выводу изображения продолжают действовать. Обновление данных с CPU и освобождение ресурсов тоже должны ждать, пока GPU закончит использовать соответствующую память.'
concepts.synchronization.dependencies.details: 'Выбор механизма зависит от места выполнения операций:'
-concepts.synchronization.dependencies.guidance: 'Одной задаче может потребоваться несколько механизмов. Например, текстуре, созданной вычислениями в другой очереди, нужны зависимость между отправками и подходящее состояние для следующего обращения. Блокировать CPU при этом нужно только тогда, когда он сам должен обратиться к данным или освободить их память.'
+concepts.synchronization.dependencies.guidance: 'Если одна очередь записывает данные в текстуру, а другая их использует, задайте зависимость между отправками и запишите необходимый переход состояния. Ни одно из этих действий не блокирует CPU. Перед обращением CPU к данным или освобождением ресурса дождитесь завершения работы.'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: Вызов {wait} для соответствующего значения завершения.
concepts.synchronization.dependencies.table.cpuAccess.situation: 'Доступ CPU или освобождение ресурса требует завершения работы GPU'
concepts.synchronization.dependencies.table.crossQueue.mechanism: 'Передайте {timelineValue} производителя в вызов {submit} потребителя.'
@@ -231,18 +229,18 @@ concepts.synchronization.layouts.description: 'Флаги назначения
concepts.synchronization.layouts.details: 'Здесь {outputTexture} создана с назначением {sampledStorage}, а выбранный подресурс находится в {storage}. {default} выбирает уровень mip 0 и слой 0. Остальные уровни и слои переход не затрагивает.'
concepts.synchronization.layouts.guidance: 'В {transition} передавайте состояние предыдущего использования подресурса. Приложение отслеживает это состояние при записи команд и передаче текстур между этапами рендеринга.'
concepts.synchronization.layouts.title: 'Состояния текстур'
-concepts.synchronization.readback.description: '{isCompleted} сообщает о завершении работы GPU. У записанного считывания есть ещё один этап: копирование результата из внутренней промежуточной памяти в память назначения приложения.'
+concepts.synchronization.readback.description: '{isCompleted} сообщает о завершении работы GPU. У записанного считывания есть ещё один этап: копирование результата из внутренней памяти для считывания в память назначения приложения.'
concepts.synchronization.readback.details: '{commandBufferDownload} записывает копирование на GPU во внутреннюю память. После завершения отправки библиотека выполняет копию на CPU, возвращая командный буфер для повторного использования. Вызов {wait} для значения этой отправки дожидается GPU и обрабатывает завершённые буферы той же очереди, тем самым завершая оба этапа. До возврата память назначения должна оставаться выделенной, а управляемая память — закреплённой.'
-concepts.synchronization.readback.guidance: 'Один лишь опрос {isCompleted} не выполняет заключительную копию на CPU. Ожидание другой очереди тоже не возвращает завершённые буферы очереди считывания. Когда загрузка и считывание используют прямой доступ к памяти, а когда промежуточное хранилище, описано в статье «{link}».'
+concepts.synchronization.readback.guidance: 'Один лишь опрос {isCompleted} не выполняет заключительную копию на CPU. Ожидание другой очереди тоже не обрабатывает завершённые командные буферы очереди считывания. Когда загрузка и считывание используют прямой доступ к памяти, а когда промежуточное хранилище, описано в статье «{link}».'
concepts.synchronization.readback.guidance.link: Управление ресурсами
-concepts.synchronization.readback.title: 'Готовность данных к чтению'
+concepts.synchronization.readback.title: 'Завершение считывания'
concepts.synchronization.reuse.description: 'Треугольник дожидается завершения каждого кадра перед повторным использованием данных. Чтобы выполнение кадров перекрывалось, выделите каждому ещё выполняющемуся кадру собственную изменяемую память и отслеживайте, когда она снова станет доступной. Перед изменением данных дождитесь обращений GPU к тем же байтам, а перед освобождением ресурса — всех его незавершённых использований.'
concepts.synchronization.reuse.details: 'Изменение размера и завершение приложения подчиняются тому же правилу: прекратить новые обращения, дождаться текущих, затем заменить или освободить ресурсы. Соблюдайте этот порядок перед {swapChainResize} и перед освобождением ресурсов или контекста. Треугольник уже ждёт каждый кадр, поэтому может менять размер между вызовами обработчиков.'
concepts.synchronization.reuse.guidance: 'После вывода изображения {swapChainPresent} устанавливает точку завершения в графической очереди и ожидает её. Поэтому треугольник всё равно ждёт при выводе, даже если удалить явное ожидание после отправки команд. Работа, независимо отправленная в другие очереди, требует отдельного отслеживания завершения.'
concepts.synchronization.reuse.title: 'Повторное использование ресурсов'
concepts.synchronization.timelines.context: 'Если после потребителя CPU должен прочитать результат, перезаписать общие данные или освободить ресурсы, дождитесь этой отправки:'
concepts.synchronization.timelines.description: 'Временная шкала отмечает завершение в очереди возрастающими значениями. {submit} возвращает {timelineValue} со шкалой и значением отправки. Числовые поля {value} разных шкал нельзя сравнивать напрямую.'
-concepts.synchronization.timelines.details: 'Пусть {producer} и {consumer} — записанные буферы двух очередей одного контекста, причём потребитель читает результат производителя. Отправьте их с такой зависимостью:'
+concepts.synchronization.timelines.details: 'Пусть {producer} и {consumer} — записанные командные буферы двух очередей одного контекста, причём потребитель читает результат производителя. Отправьте их с такой зависимостью:'
concepts.synchronization.timelines.guidance: 'Очередь-потребитель ждёт указанного значения завершения перед выполнением своих команд. CPU может продолжать работу без вызова {producedWait}. Сохраняйте общие ресурсы до завершения {consumed} и записывайте переходы состояния текстур, необходимые для доступа потребителя.'
concepts.synchronization.timelines.notes: 'Значение, возвращённое {queueTimelineSignal}, также можно ожидать через {wait} или передать как зависимость другой очереди. {signal} помещает точку завершения после ранее отправленной работы; GPU достигает её, когда эта работа закончена.'
concepts.synchronization.timelines.title: 'Временные шкалы и зависимости очередей'
@@ -256,7 +254,7 @@ home.entries.reference.category: Справочник
home.entries.reference.description: 'Справка по типам, членам и объявлениям API'
home.entries.reference.title: Справочник API
home.entries.samples.action: Обзор примеров
-home.entries.samples.category: Примеры
+home.entries.samples.category: Примеры кода
home.entries.samples.description: 'Рабочие примеры графических и вычислительных методов'
home.entries.samples.title: Примеры
home.entries.title: 'Документация'
@@ -265,22 +263,22 @@ home.entries.tutorial.category: 'Урок'
home.entries.tutorial.description: 'От пустого проекта до первого треугольника на экране'
home.entries.tutorial.title: Первый треугольник
home.introduction.accent: 'на разных платформах'
-home.introduction.description: 'Zenith.NET объединяет работу с DirectX, Metal и Vulkan в одном API для графики и вычислений'
+home.introduction.description: 'Zenith.NET предоставляет единый API для графики и вычислений в DirectX 12, Metal 4 и Vulkan 1.4'
home.introduction.title: 'Графика для .NET{lineBreak}{accent}'
-home.meta.description: 'Кроссплатформенная графика и вычисления в .NET с единым API для DirectX, Metal и Vulkan'
+home.meta.description: 'Кроссплатформенная графика и вычисления в .NET с единым API для DirectX 12, Metal 4 и Vulkan 1.4'
home.scene.description: 'Интерактивная вращающаяся геометрия. Перетаскивайте изображение или используйте клавиши со стрелками для изменения ракурса.'
home.scene.label: Отображение геометрии
home.scene.surface: Поверхность
home.scene.wireframe: Каркас
-home.title: 'Графический API для .NET'
+home.title: 'Современный RHI для .NET'
learning.concepts.description: 'Выбор назначений ресурсов, описание данных шейдеров и координация работы GPU'
learning.concepts.execution.description: 'Запись команд, отправка и время жизни ресурсов'
-learning.concepts.platforms.description: 'Нативный вывод и графические элементы интерфейса'
+learning.concepts.platforms.description: 'Нативный вывод и элементы управления для рендеринга в интерфейсе'
learning.concepts.resources.description: 'Назначения ресурсов, размещение памяти и представления'
learning.concepts.shaders.description: 'Соглашения о размещении и привязке данных C# и Slang'
learning.concepts.synchronization.description: 'Зависимости, видимость и завершение'
learning.concepts.title: Основные концепции
-learning.description: 'Начните с урока о треугольнике и создайте первое приложение. Затем изучите управление ресурсами, данные шейдеров и синхронизацию в статьях об основных понятиях или выберите пример нужного графического метода.'
+learning.description: 'Начните с урока о треугольнике и создайте первое приложение. Затем изучите управление ресурсами, данные шейдеров и синхронизацию в статьях об основных понятиях или выберите пример нужного метода.'
learning.entries.samples.action: Обзор примеров
learning.entries.samples.description: 'Примеры на C# и Slang: геометрия, вычисления, запросы лучей и меш-шейдинг'
learning.entries.tutorial.action: 'Открыть урок'
@@ -288,73 +286,67 @@ learning.entries.tutorial.description: 'Консольное приложени
learning.meta.description: 'Учебные материалы и основы модели программирования Zenith.NET'
learning.title: Обучение
reference.description: 'Справочник ресурсов, команд и платформенных интеграций'
-reference.entries.commands.description: 'Графические, вычислительные и передающие команды'
+reference.entries.commands.description: 'Графические и вычислительные команды, а также команды передачи данных'
reference.entries.commands.label: Запись команд
-reference.entries.context.description: 'Создание ресурсов GPU для выбранного бэкенда'
+reference.entries.context.description: 'Создание ресурсов GPU через графический контекст'
reference.entries.context.label: Начало работы
reference.meta.description: 'Пространства имён, типы и члены Zenith.NET'
reference.navigation.core: 'Справочник основного API'
reference.title: Справочник API
-samples.computeShader.description: 'Пример загружает {assetsTexturesShokoPng}, преобразует изображение в оттенки серого на GPU и показывает выходную текстуру. Преобразование выполняется один раз; следующие кадры показывают тот же результат. Рендерер демонстрирует привязку текстур для выборки и записи, округление числа групп потоков вверх для обработки всего изображения и проверку его границ в шейдере.'
+samples.computeShader.description: 'Вычислительный шейдер преобразует цветное изображение в оттенки серого и демонстрирует обработку изображений на GPU.'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: Вычислительный шейдер
-samples.cube.description: 'Куб добавляет индексированное рисование, матрицы модели, вида и проекции в буфере констант и проверку глубины. Текстура глубины и трафарета {d32FloatS8UInt} пересоздаётся при изменении размера.'
+samples.cube.description: 'Вращающийся куб знакомит с индексированной геометрией, трёхмерными преобразованиями и проверкой глубины.'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: Вращающийся куб
-samples.description: 'Каждый пример объединяет рендерер C# и шейдер Slang для определённого метода. Полную настройку приложения и порядок рендеринга разбирает урок «{link}».'
-samples.description.link: Первый треугольник
+samples.description: 'Эти примеры охватывают рендеринг и вычисления — от одного треугольника до интерактивных приложений и диагностических утилит.'
samples.execution.description: 'Запустите проект {link} и выберите пример в меню консоли.'
samples.execution.description.link: ZenithTutorials
samples.execution.title: 'Запуск примеров'
-samples.host.description: '{appCs} инициализирует контекст, окно и цепочку обмена. На каждом кадре он получает буфер команд, вызывает выбранный рендерер, отправляет команды и выводит изображение. {iRendererCs} задаёт операции обновления, рисования, изменения размера и освобождения ресурсов.'
-samples.host.details: 'Вычислительный рендерер и рендерер трассировки лучей создают внеэкранные текстуры. {texturePresenterCs} и {presentTextureSlang} рисуют их в текущую выходную текстуру, после чего общая оболочка отправляет команды и выводит кадр.'
-samples.host.title: 'Оболочка приложения и вывод'
-samples.indirectDrawing.description: 'Косвенное рисование выводит несколько экземпляров куба по буферу аргументов индексированного рисования и структурированному буферу данных экземпляров. CPU задаёт аргументы и обновляет преобразования.'
+samples.indirectDrawing.description: 'Сетка вращающихся кубов разных цветов демонстрирует косвенное рисование с использованием буфера аргументов рисования.'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: 'Косвенное рисование'
-samples.meshShading.description: 'Шейдер задач отбрасывает невидимые экземпляры сфер и передаёт оставшиеся индексы меш-шейдеру, который создаёт геометрию. До создания конвейера рендерер проверяет {contextCapabilitiesMeshShadingSupported}.'
+samples.meshShading.description: 'В этом примере шейдеры задач и меш-шейдеры используются для отрисовки сетки цветных сфер; сферы вне поля зрения камеры пропускаются. Требуется поддержка меш-шейдинга.'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: 'Меш-шейдинг'
-samples.rayTracing.description: 'Пример строит структуры ускорения нижнего и верхнего уровней для пола и процедурных сфер, затем выполняет встроенные запросы лучей в вычислительном шейдере. До инициализации проверяется {contextCapabilitiesRayTracingSupported}.'
+samples.rayTracing.description: 'В этом примере запросы лучей используются для отрисовки отражающих сфер и теней на клетчатом полу. Требуется поддержка трассировки лучей.'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: Трассировка лучей
samples.title: Примеры
-samples.triangle.description: 'Треугольник связывает буфер вершин с соответствующим описанием входа и рисует три вершины через графический конвейер.'
+samples.triangle.description: 'Треугольник с плавными переходами между цветами вершин знакомит с основами графического конвейера.'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: 'Полный урок'
samples.triangle.title: 'Треугольник'
-samples.workloads.description: 'Каталог {link} основного репозитория содержит более сложные приложения, использующие исходный код библиотеки.'
+samples.workloads.description: 'Каталог {link} репозитория Zenith.NET содержит следующие приложения и утилиты.'
samples.workloads.description.link: 'Experiments'
-samples.workloads.details: 'Оконные эксперименты используют те же пути вывода для Windows, macOS и Linux/X11. Интеграции Avalonia, WinForms, WPF, WinUI/Uno и MAUI, их цикл кадров и исходный код описаны в статье «{link}».'
-samples.workloads.details.link: Интеграция с платформами
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: CornellBox
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Трассировка путей, шумоподавление, тональная компрессия, увеличение разрешения и элементы управления ImGui. Требуется поддержка трассировки лучей.'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: 'Интерактивная сцена комнаты для изучения освещения и отражений. Требуется поддержка трассировки лучей.'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: FluidTank
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Вычислительное моделирование жидкости, зависимости между стадиями симуляции и многопроходный рендеринг поверхности.'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: 'Симуляция воды в резервуаре с режимами отображения поверхности и частиц.'
samples.workloads.table.headings.example: Пример
-samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Методы и требования'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: 'Описание'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: InkCanvas
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Отрисовка с помощью Skia и обработка ввода в нативном окне. Требуется бэкенд и нативная библиотека Skia для целевой платформы.
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: Холст для рисования от руки и стирания штрихов.
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: PlatformDetection
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Пытается создать контекст для каждого бэкенда и сообщает возможности устройства. Неудачная попытка отмечается как отсутствие поддержки; причиной может быть устройство, драйвер или недостающая зависимость среды выполнения.'
-samples.workloads.title: 'Более сложные приложения'
-tutorial.context.description: '{graphicsContext} связывает приложение с GPU через выбранный бэкенд и предоставляет методы создания ресурсов для рендеринга.'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: 'Консольная утилита, которая сообщает о доступности графических API и возможностях устройства.'
+samples.workloads.title: 'Приложения и утилиты'
+tutorial.context.description: '{graphicsContext} связывает приложение с GPU через выбранный графический API и предоставляет методы создания ресурсов для рендеринга.'
tutorial.context.details: 'Вставьте инициализацию контекста {emphasis}:'
tutorial.context.details.emphasis: после директив using, перед {iWindowWindow}
-tutorial.context.guidance: 'Каждая ветвь выбирает бэкенд текущей платформы и запрашивает валидацию. Сообщения {validationMessage} выводятся в консоль.'
+tutorial.context.guidance: 'Каждая ветвь запрашивает проверку для выбранного графического API. Если реализация выдаёт диагностические сообщения {validationMessage}, обработчик выводит их в консоль.'
tutorial.context.imports: 'Добавьте следующие директивы using в начало {programCs}:'
tutorial.context.title: 'Графический контекст'
tutorial.description: 'В этом уроке из пустого консольного проекта .NET получится приложение, которое открывает окно и рисует цветной треугольник.'
tutorial.details: 'В уроке три проверочных этапа: пустое окно, однотонный фон и цветной треугольник. Запускайте приложение после каждого этапа, прежде чем добавлять следующую часть.'
tutorial.draw.context: 'Аргументы метода {draw}:'
tutorial.draw.description: 'В обработчике {windowRender} замените {addTheTriangleDrawCommandsHereLater} следующими командами между {beginRenderPass} и {endRenderPass}:'
-tutorial.draw.details: '{setPipeline} выбирает шейдеры и состояние рендеринга. Этот вызов должен предшествовать привязке вершинного буфера, поскольку бэкенд интерпретирует его данные по описанию вершинного ввода выбранного конвейера.'
+tutorial.draw.details: '{setPipeline} выбирает шейдеры и состояние рендеринга. Сначала выберите конвейер: его описание вершинного ввода определяет, как читать данные из вершинного буфера.'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} привязывает загруженные вершинные данные со смещения 0 байт к входному слоту 0, соответствующему единственной записи {inputLayouts}.'
-tutorial.draw.notes: 'Эти вызовы записывают команды рисования. Уже добавленный вызов {submitWait} отправляет их и дожидается завершения на GPU; затем {present} запрашивает вывод готового изображения. Сохраните заполнение фоном в начале прохода, чтобы область за пределами треугольника тоже имела определённый цвет.'
+tutorial.draw.notes: 'Сохраните очистку в начале прохода, чтобы область за пределами треугольника имела определённый цвет фона.'
tutorial.draw.table.firstInstance.meaning: Начать нумерацию экземпляров с нуля.
tutorial.draw.table.firstVertex.meaning: Начать с первой вершины в буфере.
tutorial.draw.table.headings.argument: Аргумент
@@ -370,25 +362,25 @@ tutorial.execution.title: 'Запуск приложения'
tutorial.frame.commands.context: 'После {endRenderPass} второй переход подготавливает выходную текстуру к выводу. {submit} завершает запись и отправляет командный буфер; {wait} блокирует поток до завершения этой работы. Затем {present} запрашивает отображение готового изображения.'
tutorial.frame.commands.description: 'Проход рендеринга объединяет команды рисования, которые записывают результаты в одни и те же вложения. В этом проходе цвет записывается в выходную текстуру цепочки обмена. {colorAttachmentClear} задаёт её начальное заполнение цветом RGBA и сохранение содержимого после прохода. {beginRenderPass} записывает начало прохода с этими настройками.'
tutorial.frame.commands.details: 'Коллекция содержит одно цветовое вложение. {null} означает, что у прохода нет вложения глубины и трафарета.'
-tutorial.frame.commands.guidance: '{beginRenderPass} задаёт область вывода и прямоугольник отсечения по размеру всего вложения. Область вывода преобразует координаты рендеринга в позиции пикселей, а прямоугольник отсечения ограничивает область, в которую разрешена запись.'
+tutorial.frame.commands.guidance: '{beginRenderPass} задаёт область вывода и прямоугольник отсечения по размеру всего вложения. Область вывода преобразует координаты рендеринга в позиции пикселей, а прямоугольник отсечения ограничивает область, в которой команды рисования могут изменять пиксели.'
tutorial.frame.commands.title: 'Очистка, отправка и вывод'
-tutorial.frame.description: 'Для начала заполните окно одним цветом фона. Эта операция называется очисткой. Когда фон появился, поверхность, отправка команд и вывод уже работают вместе — можно добавлять вершины и шейдеры треугольника.'
-tutorial.frame.details: 'Silk.NET вызывает обработчик, когда нужно отрисовать кадр. Пример не использует аргумент прошедшего времени, поэтому параметр назван {value}. Зарегистрируйте обработчик {emphasis}:'
+tutorial.frame.description: 'Сначала заполните окно одним цветом — это очистка. Если цвет появился, отправка команд и вывод работают. Затем добавьте вершины и шейдеры треугольника.'
+tutorial.frame.details: 'Silk.NET вызывает обработчик рендеринга, когда нужно отрисовать кадр. Зарегистрируйте обработчик {emphasis}:'
tutorial.frame.details.emphasis: перед {windowRun}
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} возвращает буфер, готовый к записи. Запись определяет работу GPU; выполнение начинается только после отправки.'
+tutorial.frame.target.description: 'Очередь команд принимает записанную работу для выполнения на GPU. {graphicsQueueCommandBuffer} возвращает командный буфер графической очереди, в котором уже начата запись. Записанные команды определяют работу GPU; выполнение начинается только после отправки.'
tutorial.frame.target.details: 'Состояние доступа к текстуре определяет, как операция будет её использовать. Первый вызов {transition} подготавливает выходную текстуру к записи цвета. Значение {default} выбирает mip-уровень 0 и слой массива 0 — базовое изображение этой текстуры. Поскольку проход заполняет всё изображение цветом фона, {undefined} разрешает отбросить прежнее содержимое.'
tutorial.frame.target.guidance: 'Для каждого кадра используйте текущую выходную текстуру: при выводе изображения цепочка обмена может перейти к следующей.'
tutorial.frame.target.title: 'Подготовка выходной текстуры'
tutorial.frame.title: 'Первый кадр'
tutorial.geometry.data.description: 'Добавьте массив вершин {emphasis}. Последующую инициализацию ресурсов также размещайте перед этим обработчиком в указанном порядке.'
tutorial.geometry.data.description.emphasis: перед {windowRender}
-tutorial.geometry.data.details: 'Каждая запись создаёт {vertex}; два внутренних выражения {new} задают позицию {vector3} и цвет {vector4}. Позиции соответствуют верхней, нижней правой и нижней левой вершинам. Вершинный шейдер добавляет четвёртую координату {w}. При w = 1 значения x и y также являются нормализованными координатами устройства: -1 и +1 обозначают края изображения, а 0 — центр. Эти координаты не зависят от числа пикселей.'
+tutorial.geometry.data.details: 'Три позиции задают верхнюю, нижнюю правую и нижнюю левую вершины. В этом примере x и y охватывают изображение в диапазоне от -1 до +1: 0 соответствует центру, положительные значения x направлены вправо, а положительные значения y — вверх.'
tutorial.geometry.data.guidance: 'Цвет задаётся красной, зелёной, синей и альфа-компонентами; альфа равна 1. Все три вершины находятся в одной плоскости при z = 0.'
tutorial.geometry.data.title: 'Позиции и цвета вершин'
tutorial.geometry.description: 'У каждой из трёх вершин есть позиция и цвет. По позициям GPU определяет форму треугольника, а его внутренние цвета получает интерполяцией цветов вершин.'
tutorial.geometry.format.description: 'Добавьте объявление вершины {emphasis}:'
tutorial.geometry.format.description.emphasis: 'в конце {programCs}, после кода освобождения ресурсов'
-tutorial.geometry.format.details: '{file} ограничивает использование типа файлом {programCs}, а {layoutKindSequential} сохраняет порядок объявления полей. Поле {position} содержит три 32-битных числа с плавающей точкой и начинается со смещения 0 байт; поле {color} содержит четыре таких числа и начинается со смещения 12 байт. Одна вершина занимает 28 байт. Далее описание входных данных укажет GPU, как читать эти поля.'
+tutorial.geometry.format.details: '{layoutKindSequential} сохраняет порядок объявления полей. Поле {position} содержит три 32-битных числа с плавающей точкой и начинается со смещения 0 байт; поле {color} содержит четыре таких числа и начинается со смещения 12 байт. Одна вершина занимает 28 байт. Описание входных данных укажет GPU, как читать эти поля.'
tutorial.geometry.format.imports: 'Добавьте в начало {programCs} следующие директивы using для векторных типов и атрибута размещения полей структуры:'
tutorial.geometry.format.title: 'Представление вершины'
tutorial.geometry.title: 'Вершинные данные'
@@ -397,9 +389,8 @@ tutorial.geometry.upload.description: 'Поместите вершины в {buf
tutorial.geometry.upload.details: 'Размер выделения — {sizeofVertexVerticesLength}: три вершины по 28 байт, всего 84 байта. {bufferUsagesVertex} объявляет вершинный ввод, {cpuWriteOnly} разрешает начальное заполнение с CPU. Шаг в описании буфера фиксирует размер элемента. Описание входа ниже определит интерпретацию каждого атрибута.'
tutorial.geometry.upload.guidance: 'Выделение памяти не заполняет буфер. {upload} копирует массив в начало буфера, используя исходный указатель и число байтов из описания данных.'
tutorial.geometry.upload.imports: 'В {programCs} добавьте {bufferAlias} к директивам using, чтобы отличить тип буфера Zenith.NET от {systemBuffer}.'
-tutorial.geometry.upload.notes: 'В коде освобождения в конце {programCs} вставьте {vertexBufferDispose} непосредственно перед {swapChainDispose}. Память только для GPU и загрузка крупной статической геометрии рассмотрены в статье «{link}».'
-tutorial.geometry.upload.notes.link: Управление ресурсами
-tutorial.geometry.upload.title: 'Создание и заполнение буфера'
+tutorial.geometry.upload.notes: 'В коде освобождения в конце {programCs} вставьте {vertexBufferDispose} непосредственно перед {swapChainDispose}.'
+tutorial.geometry.upload.title: 'Выделение буфера и загрузка данных'
tutorial.input.description: 'GPU нужно знать, где хранятся атрибуты вершины, например позиция и цвет. Описание входа задаёт их формат и смещение, а также шаг — расстояние в байтах до следующей вершины. Добавьте этот код после создания шейдеров:'
tutorial.input.details: '{inputLayoutAdd} размещает каждый атрибут сразу после предыдущего и увеличивает шаг между вершинами на размер добавленного атрибута. Смещения рассчитываются по указанным форматам, без анализа структуры C#. Для этих двух полей получается следующая раскладка:'
tutorial.input.guidance: 'Значение {semanticIndex} по умолчанию равно нулю и соответствует {pOSITION0} и {cOLOR0} в шейдере. Позиция и цвет хранятся вместе в одном вершинном буфере, поэтому конвейер использует одно описание входных данных в слоте 0. Если порядок полей или выравнивающие промежутки в структуре C# изменятся, измените и это описание.'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: Следующая входная
tutorial.input.table.vertexColor.format: '{float4} (16 байт)'
tutorial.input.table.vertexPosition.format: '{float3} (12 байт)'
tutorial.input.title: 'Описание вершинного входа'
-tutorial.lifecycle.description: 'Каждый кадр выполняется в таком порядке:'
-tutorial.lifecycle.details: 'После закрытия окна {run} возвращает управление, и выполнение продолжается в коде освобождения ресурсов. Каждый кадр уже дождался завершения своих команд, поэтому использованные ими ресурсы можно освободить. Полный код после {windowRun} выглядит так:'
+tutorial.lifecycle.description: 'В каждом кадре приложение получает текущую выходную текстуру, переводит её в состояние для рендеринга, очищает и рисует треугольник. Затем оно переводит текстуру в состояние для вывода, отправляет команды, дожидается завершения и выводит изображение.'
+tutorial.lifecycle.details: 'После закрытия окна {run} возвращает управление, и выполнение продолжается в коде освобождения ресурсов. В цикле рендеринга приложение уже дождалось выполнения команд каждого кадра, поэтому использованные ими ресурсы можно освободить. Полный код после {windowRun} выглядит так:'
tutorial.lifecycle.guidance: 'Освободите цепочку обмена перед уничтожением её окна, а контекст — после его ресурсов. Очередь повторно использует отправленные командные буферы, а цепочка обмена управляет своей выходной текстурой. Отдельный вызов {dispose} для этих объектов не нужен.'
-tutorial.lifecycle.title: 'Цикл кадра и освобождение ресурсов'
tutorial.pipeline.behavior: 'После описания входа создайте конвейер:'
tutorial.pipeline.context: '{cullNone} отключает отбрасывание граней. Треугольник будет нарисован независимо от того, расположены ли его вершины на экране по часовой стрелке или против неё.'
tutorial.pipeline.description: '{graphicsPipeline} объединяет описание вершин, два шейдера и настройки сборки примитивов и записи во вложения.'
-tutorial.pipeline.details: 'Шейдеры обрабатывают вершины и фрагменты. Остальные настройки конвейера управляют сборкой примитивов, отбрасыванием граней, проверкой глубины и смешиванием цветов:'
tutorial.pipeline.guidance: 'Цветовой формат конвейера должен совпадать с вложением прохода, поэтому берётся из {swapChainDescFormat}. {count1} задаёт одну выборку на пиксель.'
tutorial.pipeline.item: '{triangleList} собирает каждую последовательную тройку вершин в треугольник.'
tutorial.pipeline.notes: '{depthNone} отключает проверку и запись глубины, что соответствует отсутствию вложения глубины.'
@@ -428,28 +417,25 @@ tutorial.pipeline.reference: '{opaque} отключает смешивание.
tutorial.pipeline.title: 'Графический конвейер'
tutorial.pipeline.usage: 'Объекты шейдеров можно освободить после создания конвейера. Сам конвейер сохраняйте на время рендеринга; в коде освобождения добавьте {pipelineDispose} перед {vertexBufferDispose}.'
tutorial.presentation.title: 'Графический контекст и вывод'
-tutorial.project.context: 'В настройках сборки включите «{emphasis}» ({allowUnsafeBlocks}). Небезопасный код нужен для нативных вызовов вспомогательного оконного кода и загрузки вершин.'
+tutorial.project.context: 'В настройках сборки включите «{emphasis}» ({allowUnsafeBlocks}). Небезопасный код нужен для нативных вызовов вспомогательного класса для окна и загрузки вершин.'
tutorial.project.context.emphasis: Разрешить небезопасный код
tutorial.project.description: 'Создайте консольный проект C# с именем {firstTriangle} для .NET 10.'
tutorial.project.details: 'Добавьте в проект следующие пакеты NuGet:'
-tutorial.project.guidance: '{zenithNET} предоставляет общий API рендеринга, а три пакета бэкендов — его платформенные реализации. {zenithNETCompiler} компилирует шейдеры Slang для выбранного бэкенда. Silk.NET создаёт окно и обрабатывает события.'
+tutorial.project.guidance: '{zenithNET} предоставляет общий API для графики и вычислений; три пакета для графических API реализуют его. {zenithNETCompiler} компилирует шейдеры Slang для выбранного API.'
tutorial.project.title: 'Настройка проекта'
-tutorial.requirements.context: 'Образцы кода для этого урока — {link} и его {detail}.'
-tutorial.requirements.context.detail: 'общая оболочка'
-tutorial.requirements.context.link: 'пример Hello Triangle'
-tutorial.requirements.description: 'Нужны {emphasis} и базовое знание C#. Приложение предназначено для {net10}. GPU и драйвер должны поддерживать бэкенд, выбранный для вашей платформы:'
+tutorial.requirements.description: 'Нужны {emphasis} и базовые знания C#. GPU и драйвер должны поддерживать следующие графические возможности для вашей платформы:'
tutorial.requirements.description.emphasis: .NET 10 SDK
-tutorial.requirements.guidance: 'Zenith.NET выполняет рендеринг на нативной поверхности, предоставленной приложением. Silk.NET.Windowing создаёт окно и обрабатывает его события. На macOS для вывода используется слой Metal, представленный в {cAMetalLayerCs}; вспомогательный код связывает его с окном.'
-tutorial.requirements.table.headings.graphicsBackend: Графический бэкенд
+tutorial.requirements.guidance: 'Zenith.NET выполняет рендеринг на нативной поверхности, предоставленной приложением. Silk.NET.Windowing создаёт окно и обрабатывает его события.'
+tutorial.requirements.table.headings.graphicsBackend: 'Требования к графике'
tutorial.requirements.table.headings.platform: Платформа
-tutorial.requirements.table.linux.graphicsBackend: Vulkan 1.4
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 с VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux (X11 или XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: Metal 4
tutorial.requirements.table.macOS.platform: macOS
-tutorial.requirements.table.windows.graphicsBackend: DirectX 12
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 с Shader Model 6.6'
tutorial.requirements.table.windows.platform: Windows
tutorial.requirements.title: 'Необходимые условия'
-tutorial.resize.context: 'Снова соберите и запустите приложение. Фон должен заполнять всё окно и после изменения его размера: каждый новый проход задаёт область вывода и прямоугольник отсечения по размерам вложения. Сохраните обработчик рендеринга — в его проход будет добавлено рисование треугольника.'
+tutorial.resize.context: 'Снова соберите и запустите приложение. Фон должен заполнять всё окно и после изменения его размера. Сохраните обработчик рендеринга — в его проход будет добавлено рисование треугольника.'
tutorial.resize.description: 'Размер изображений цепочки обмена должен соответствовать кадровому буферу. Зарегистрируйте обработчик {framebufferResize} после обработчика рендеринга и перед {windowRun}:'
tutorial.resize.details: 'Отслеживайте {link}, измеряемые в пикселях, а не изменения логических размеров окна. Если при сворачивании окна ширина или высота кадрового буфера становится нулевой, обработчик изменения размера оставляет цепочку обмена без изменений. Обработчик рендеринга тоже сразу возвращается, пока хотя бы один размер равен нулю. Рендеринг возобновляется, когда размеры снова позволяют вывести изображение.'
tutorial.resize.details.link: 'изменения размера кадрового буфера'
@@ -458,60 +444,42 @@ tutorial.resize.guidance.link: Синхронизация
tutorial.resize.title: 'Изменение размера'
tutorial.shaders.compilation.context: '{appContextBaseDirectory} позволяет загрузить копию шейдера из выходного каталога приложения. Поэтому запуск из другого рабочего каталога не меняет место поиска файла.'
tutorial.shaders.compilation.description: 'В свойствах {triangleSlang} задайте параметру «{emphasis}» значение «{detail}». При сборке шейдер будет скопирован рядом с исполняемым файлом.'
-tutorial.shaders.compilation.description.detail: Копировать более позднюю версию
+tutorial.shaders.compilation.description.detail: Копировать, если файл новее
tutorial.shaders.compilation.description.emphasis: Копировать в выходной каталог
tutorial.shaders.compilation.details: 'В {programCs} добавьте инициализацию шейдеров после загрузки вершин и до обработчика рендеринга:'
tutorial.shaders.compilation.guidance: '{zenithCompiler} компилирует исходный код для {contextGraphicsApi}, а {createShader} создаёт объект шейдера из полученного описания. Имена точек входа {vSMain} и {fSMain} выбирают две функции, определённые в файле Slang.'
tutorial.shaders.compilation.title: 'Компиляция шейдеров'
tutorial.shaders.context: '{fSInput} связывает две шейдерные стадии. Вершинный шейдер записывает в {sVPOSITION} позицию в пространстве отсечения; по ней GPU определяет видимую часть треугольника. Поле {cOLOR0} передаёт цвет вершины, который интерполируется по треугольнику перед поступлением во фрагментный шейдер. Тип и семантика этого поля должны совпадать между стадиями.'
tutorial.shaders.description: 'Шейдеры — программы, выполняемые на GPU. Вершинный шейдер определяет положение каждой вершины, а фрагментный — цвет в точках изображения, покрытых треугольником. Обе стадии будут записаны в одном файле Slang. Для каждой задаётся отдельная точка входа — функция, с которой начинается выполнение.'
-tutorial.shaders.details: 'Создайте {triangleSlang} с этими структурами входа и выхода:'
+tutorial.shaders.details: 'Создайте {triangleSlang} в корне проекта с этими структурами входа и выхода:'
tutorial.shaders.fragment.description: 'Добавьте в тот же файл точку входа фрагментного шейдера:'
tutorial.shaders.fragment.details: 'Растеризация определяет, какие точки изображения покрывает треугольник, и создаёт для них фрагменты. Каждый фрагмент получает цвет, интерполированный из цветов трёх вершин. {fSMain} возвращает этот цвет, а {sVTARGET} направляет результат в первое цветовое вложение.'
tutorial.shaders.fragment.title: 'Фрагментный шейдер'
tutorial.shaders.guidance: '{vSInput} задаёт вход вершинного шейдера. {pOSITION0} и {cOLOR0} связывают атрибуты по семантикам; одних имён полей C# для этого недостаточно.'
tutorial.shaders.title: 'Стадии шейдеров'
tutorial.shaders.vertex.description: 'Добавьте в {triangleSlang} точку входа вершинного шейдера:'
-tutorial.shaders.vertex.details: 'GPU вызывает её для каждой входной вершины. Функция добавляет однородную координату {w} и передаёт цвет. После обработки вершин позиция делится на w. Здесь w = 1, поэтому x, y и z не меняются и непосредственно задают нормализованные координаты устройства.'
+tutorial.shaders.vertex.details: 'GPU выполняет эту функцию для каждой входной вершины. Функция добавляет четвёртую компоненту позиции, {w}, и передаёт цвет. После обработки вершин GPU делит x, y и z на w, получая нормализованные координаты устройства. При w, равном 1, эти значения не меняются.'
tutorial.shaders.vertex.title: 'Вершинный шейдер'
tutorial.surface.description: 'Задайте нативную поверхность вывода {emphasis}:'
tutorial.surface.description.emphasis: после {windowCenter} и перед {windowRun}
tutorial.surface.details: 'Кадровый буфер — изображение окна в пикселях. {surface} описывает нативный объект вывода и его размеры; {framebufferSize} сообщает размер в пикселях. При масштабировании экрана он может отличаться от логического размера окна.'
-tutorial.surface.guidance: 'Поверхность предоставляет нативные дескрипторы выбранного бэкенда: окно Win32 в Windows, дисплей и окно X11 в Linux или прикреплённый слой Metal в macOS.'
+tutorial.surface.guidance: 'Поверхность предоставляет нативные дескрипторы для выбранного графического API: окно Win32 в Windows, дисплей и окно X11 в Linux или прикреплённый слой Metal в macOS.'
tutorial.surface.title: 'Нативная поверхность'
tutorial.swapChain.context: 'Цепочка обмена зависит от контекста и окна. Замените {windowDispose} в конце {programCs} следующим порядком освобождения:'
tutorial.swapChain.description: 'Создайте цепочку обмена сразу после описания поверхности:'
-tutorial.swapChain.details: '{swapChain} управляет изображениями, выводимыми в окно. {drawable} предоставляет текущее изображение в виде {texture} — ресурса для хранения изображения в API. После рендеринга {present} запрашивает его вывод и переходит к следующей выходной текстуре.'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} хранит четыре 8-битных канала в порядке синий, зелёный, красный, альфа. {uNorm} отображает целые 0–255 в значения 0–1. Выход шейдера остаётся логическим RGBA; формат задаёт представление в памяти. Конвейер использует {swapChainDescFormat} для соответствия вложению.'
+tutorial.swapChain.details: '{swapChain} управляет изображениями, выводимыми в окно. {drawable} предоставляет текущее изображение в виде {texture} — ресурса API для изображений. После рендеринга {present} запрашивает его вывод и переходит к следующей выходной текстуре.'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} хранит четыре 8-битных канала в порядке синий, зелёный, красный, альфа. {uNorm} отображает целые 0–255 в значения 0–1. Шейдер выдаёт логическое значение RGBA, а формат определяет его представление в памяти.'
tutorial.swapChain.title: 'Цепочка обмена'
tutorial.title: Первый треугольник
-tutorial.troubleshooting.description: 'Используйте сообщения консоли и три контрольных результата, чтобы определить этап ошибки:'
-tutorial.troubleshooting.details: '{link} и {detail} служат образцами для проверки данных вершин, описания вершинного ввода и команд рисования. В этом примере создание окна и отправка команд вынесены в общую оболочку; в уроке весь порядок работы приложения остаётся в {programCs}. Пример «{context}» знакомит с индексированным рисованием, преобразованиями и проверкой глубины.'
-tutorial.troubleshooting.details.context: Вращающийся куб
-tutorial.troubleshooting.details.detail: шейдер Slang
-tutorial.troubleshooting.details.link: 'Демонстрационный рендерер'
-tutorial.troubleshooting.table.backend.check: Убедитесь, что выбранный бэкенд поддерживается устройством и установленным графическим драйвером.
-tutorial.troubleshooting.table.backend.symptom: Сбой создания бэкенда
-tutorial.troubleshooting.table.drawing.check: 'Проверьте размер загрузки, описание вершинного входа, выбор конвейера и расположение команд рисования внутри прохода.'
-tutorial.troubleshooting.table.drawing.symptom: Фон отображается, но треугольника нет
-tutorial.troubleshooting.table.headings.check: Что проверить
-tutorial.troubleshooting.table.headings.symptom: Симптом
-tutorial.troubleshooting.table.input.check: 'Проверьте шаг в 28 байт и смещения положения и цвета: 0 и 12.'
-tutorial.troubleshooting.table.input.symptom: Искажены координаты или цвета вершин
-tutorial.troubleshooting.table.shaders.check: Проверьте скопированный файл {triangleSlang}, правильность написания точек входа и сообщения об ошибках от компилятора.
-tutorial.troubleshooting.table.shaders.symptom: Очистка цветом работает, но загрузка шейдеров завершается ошибкой
-tutorial.troubleshooting.table.window.check: Убедитесь, что проект .NET собирается и шаг с простым окном выполняется в сессии рабочего стола. В Linux проверьте доступность X11 или XWayland.
-tutorial.troubleshooting.table.window.symptom: Окно не открывается
-tutorial.troubleshooting.title: 'Диагностика ошибок'
tutorial.window.description: 'Скачайте {cocoaHelperCs} в проект. Этот вспомогательный класс связывает слой Metal с окном macOS.'
-tutorial.window.details: 'Замените сгенерированный код {programCs} следующим. Операторы верхнего уровня выполняются по порядку без явно объявленного метода {main}. В следующих разделах будет указано, куда добавлять каждый фрагмент:'
-tutorial.window.guidance: '{graphicsAPINone} оставляет создание графического контекста за Zenith.NET. {initialize} создаёт нативное окно и открывает доступ к дескрипторам оконной системы. {center} размещает окно по центру экрана. {run} обрабатывает события до закрытия окна, после чего {dispose} освобождает его.'
-tutorial.window.notes: 'Соберите и запустите приложение. Убедитесь, что окно открывается и закрывается, его можно перемещать и менять его размер. Содержимое пока не определено, поскольку команды рендеринга ещё не отправлены. Закройте окно перед продолжением.'
+tutorial.window.details: 'Замените содержимое {programCs} следующим кодом:'
+tutorial.window.guidance: '{graphicsAPINone} отключает создание графического контекста в Silk.NET. Позднее приложение создаёт контекст Zenith.NET. {initialize} создаёт нативное окно и открывает доступ к дескрипторам оконной системы. {center} размещает окно по центру экрана. {run} обрабатывает события до закрытия окна, после чего {dispose} освобождает его.'
+tutorial.window.notes: 'Соберите и запустите приложение. Убедитесь, что окно открывается, перемещается, меняет размер и закрывается. Содержимое пока не определено, поскольку команды рендеринга ещё не отправлены. Закройте окно перед продолжением.'
tutorial.window.title: 'Создание окна'
ui.action.copy: Копировать
ui.action.navigate: Перейти
ui.action.open: Открыть
-ui.action.source: Исходный код
+ui.action.source: Просмотреть исходный код
ui.api.browse: Обзор пространств имён и типов.
ui.api.clearTypeSearch: Очистить поиск типов
ui.api.findType: Найти тип
@@ -525,12 +493,12 @@ ui.api.noNamespaceTypes: В этом пространстве имён нет т
ui.api.noTypes: Совпадающих типов не найдено.
ui.api.types: Типы
ui.content.reference: Справочник
-ui.content.source: Исходный код
+ui.content.examples: Примеры кода
ui.content.tutorial: 'Урок'
ui.contents.close: Закрыть оглавление
ui.contents.open: Открыть оглавление
ui.contents.title: Содержание
-ui.footer.caption: 'Графический API для .NET'
+ui.footer.caption: 'Современный RHI для .NET'
ui.footer.label: Нижний колонтитул
ui.language.label: Язык
ui.language.unavailable: Не переведено
@@ -562,7 +530,6 @@ ui.reference.exceptions: Исключения
ui.reference.extensionMethods: Методы расширения
ui.reference.fields: Поля
ui.reference.implementations: Явные реализации интерфейса
-ui.reference.implements: Реализует
ui.reference.inheritance: Наследование
ui.reference.inheritedMembers: Унаследованные члены
ui.reference.interfaces: Интерфейсы
@@ -584,7 +551,7 @@ ui.reference.values: Значения
ui.search.close: Закрыть поиск
ui.search.empty: По запросу «{query}» ничего не найдено.
ui.search.hint: 'Поиск по урокам, основным понятиям, примерам и справочнику API.'
-ui.search.loading: Загрузка поиска…
+ui.search.loading: Подготовка поиска…
ui.search.more: Показать больше результатов
ui.search.pending: Поиск…
ui.search.placeholder: Что вы ищете?
diff --git a/documents/locales/ru-RU/translation.md b/documents/locales/ru-RU/translation.md
index cccf8146..fcf3c0ed 100644
--- a/documents/locales/ru-RU/translation.md
+++ b/documents/locales/ru-RU/translation.md
@@ -65,6 +65,8 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
## Терминология
+DirectX 12, Metal 4 и Vulkan 1.4 называйте «графическими API», а поддерживающие их код и пакеты — «реализациями соответствующих API».
+
| Английский термин | Принятый вариант |
| ----------------- | ------------------------------------------------------------------------------------------------------------- |
| API / GPU / RHI | Сохранять сокращения и пояснять их по оригиналу |
@@ -73,6 +75,7 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
| command buffer | командный буфер |
| command queue | очередь команд |
| drawable | выходная текстура текущего кадра; `Drawable` не изменять и не считать обязательно изображением цепочки обмена |
+| graphics API | графический API |
| graphics context | графический контекст |
| pipeline | конвейер |
| readback | считывание данных с GPU |
diff --git a/documents/locales/zh-CN/strings.yml b/documents/locales/zh-CN/strings.yml
index c20b4be4..3c6e82b4 100644
--- a/documents/locales/zh-CN/strings.yml
+++ b/documents/locales/zh-CN/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: '{graphicsContext} 通过特定后端连接应用程序与 GPU 设备,并提供图形、计算和传输队列。配合使用的资源必须属于同一上下文;缓冲区、纹理、着色器、管线及其句柄不能跨上下文绑定。'
+concepts.execution.context.description: '{graphicsContext} 通过所选图形 API 连接应用程序与 GPU 设备,并提供图形、计算和传输队列。配合使用的资源必须属于同一上下文;缓冲区、纹理、着色器、管线及其句柄不能跨上下文绑定。'
concepts.execution.context.details: '{capabilities} 提供设备名称与支持的功能。创建光线追踪或网格着色所需的资源前,分别通过 {rayTracingSupported} 和 {meshShadingSupported} 检查支持情况。{link}与{detail}示例展示了初始化时的检查方式。'
concepts.execution.context.details.detail: '网格着色'
concepts.execution.context.details.link: '光线追踪'
@@ -26,7 +26,7 @@ concepts.execution.pipelines.guidance.detail: '计算示例'
concepts.execution.pipelines.guidance.link: '三角形的渲染回调'
concepts.execution.pipelines.title: '管线状态'
concepts.execution.queues.description: '一帧同时包含绘制、计算和复制时,通常从 {graphicsQueue} 开始。将有依赖的操作放在同一队列,有助于明确执行顺序。'
-concepts.execution.queues.details: '不同队列可以分别接收独立的工作负载,但未必对应独立的硬件引擎。若工作能够从重叠执行中受益,再考虑增加队列。当一个队列使用另一个队列生成的数据时,需要在两次提交之间建立显式依赖。'
+concepts.execution.queues.details: '增加队列有助于让独立的工作负载重叠执行,但队列未必对应独立的硬件引擎。一个队列要使用另一队列写入的数据时,应在两次提交之间建立显式依赖。'
concepts.execution.queues.guidance: '即使位于同一队列,有依赖的操作也可能需要屏障或纹理转换,才能让后续访问读到此前写入的结果。这种内存依赖与提交顺序不同,具体表达方式见{link}。'
concepts.execution.queues.guidance.link: '同步'
concepts.execution.queues.table.computeQueue.workToRecord: '计算分派以及兼容的传输工作,不含图形渲染通道。'
@@ -42,17 +42,15 @@ concepts.execution.recording.guidance: '录制构造命令序列,{submit} 安
concepts.execution.recording.title: '录制与提交'
concepts.execution.title: '执行模型'
concepts.platforms.description: '呈现流程可以由应用程序管理,也可以交给 UI 渲染控件。这决定了谁来获取当前帧的输出纹理、录制和提交命令,以及显示渲染结果。'
-concepts.platforms.frame.context: '在通道内绑定管线并录制绘制命令,处理程序返回前须结束通道。控件负责提交命令并呈现结果;处理程序不得自行提交命令缓冲区,也不得释放传入的命令缓冲区或输出纹理。若改变了输出纹理的布局,返回前须恢复为 {colorAttachment},以便控件完成最后的转换。'
+concepts.platforms.frame.context: '在通道内绑定管线并录制绘制命令,处理程序返回前须结束通道。处理程序不得自行提交命令缓冲区,也不得释放传入的命令缓冲区或输出纹理。若改变了输出纹理的布局,返回前须恢复为 {colorAttachment},以便控件完成最后的转换。'
concepts.platforms.frame.description: '各控件实现 {iZenithView} 接口。应用程序设置 {graphicsContext},在 {updateRequested} 中更新场景,并在 {renderRequested} 中通过传入的 {renderEventArgs} 录制命令。'
concepts.platforms.frame.details: '每帧,控件获取输出纹理与命令缓冲区,将输出纹理转换为 {colorAttachment},再调用更新和渲染处理程序。之后,控件提交录制的工作,并通过对应框架的呈现机制显示图像。'
concepts.platforms.frame.guidance: '先在文件中添加 {usingZenithNET}。假定名为 {view} 的 {iZenithView} 实例已初始化并设置图形上下文,可注册以下处理程序清除其输出纹理:'
concepts.platforms.frame.notes: '初始转换使用 {undefined},允许丢弃先前图像的内容。因此,每帧都应重新绘制或清除整张图像。需要累积或缓存的渲染结果,可保存在应用程序拥有的纹理中,再将该纹理绘制到控件的输出纹理上。'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} 提供这些集成使用的默认颜色格式。'
concepts.platforms.frame.title: '通过 UI 控件渲染'
concepts.platforms.integration.context: 'WinForms、WPF 和 Windows 版 WinUI 集成运行于 Windows。使用 MAUI 时,安装目标平台的工作负载,并通过 {useZenithView} 注册控件处理程序,具体见 {extensionsCs}。'
concepts.platforms.integration.description: '控件共享事件接口,但呈现机制因框架而异:'
-concepts.platforms.integration.details: '各实现将 GPU 图像送到 UI 的方式不同。位图回读先将像素复制到 CPU 内存,再显示图像;共享纹理互操作可以省去这次 CPU 复制,但仍可能需要 GPU 复制与同步。选择集成方式时,除了共用的 {renderRequested} 事件接口,也应考虑其呈现路径。'
-concepts.platforms.integration.guidance: '通过 NuGet 添加所用 UI 框架的集成包。Avalonia 对应的包为 {avaloniaPackage}。'
+concepts.platforms.integration.details: 'UI 集成呈现 GPU 图像的方式各不相同。位图回读先将像素复制到 CPU 内存再显示;共享纹理互操作可省去这次复制,但仍可能需要 GPU 复制和同步。选择集成方式时,应同时考虑呈现路径与共用的 {renderRequested} 事件。'
concepts.platforms.integration.table.avalonia.integration: 'Avalonia'
concepts.platforms.integration.table.avalonia.presentation: '渲染到纹理后,将像素回读到 {writeableBitmap},实现见 {zenithViewCs} 和 {surfaceCs}。'
concepts.platforms.integration.table.headings.integration: '集成'
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: '呈现机制'
concepts.platforms.integration.table.maui.integration: '.NET MAUI'
concepts.platforms.integration.table.maui.presentation: 'Android、iOS 和 Mac Catalyst 使用原生呈现目标;Windows 使用共享纹理合成,具体见{link}。'
concepts.platforms.integration.table.maui.presentation.link: '平台实现'
-concepts.platforms.integration.table.uno.integration: 'Uno 路径'
+concepts.platforms.integration.table.uno.integration: 'Uno Platform'
concepts.platforms.integration.table.uno.presentation: '将像素回读到 {writeableBitmap},实现见 {zenithViewUnoCs}。'
concepts.platforms.integration.table.winForms.integration: 'WinForms'
concepts.platforms.integration.table.winForms.presentation: '为控件的 {hWND} 创建 Zenith.NET 交换链,实现见 {zenithViewCs}。'
@@ -76,28 +74,28 @@ concepts.platforms.lifecycle.guidance: '应用程序的深度纹理或离屏纹
concepts.platforms.lifecycle.guidance.link: '旋转立方体渲染器'
concepts.platforms.lifecycle.title: '交换链尺寸与生命周期'
concepts.platforms.ownership.description: '应用程序拥有所设置的上下文及其渲染资源,控件拥有呈现资源。视图的 {graphicsContext} 变化后,调度程序会为新上下文重建控件资源。应用程序也须为该上下文重建自己的管线、缓冲区和纹理。'
-concepts.platforms.ownership.details: '替换渲染资源前,先停止视图的帧活动,并等待使用这些资源的 GPU 工作完成,再释放旧资源或上下文。移除视图后,所设置的上下文仍由应用程序负责释放。'
+concepts.platforms.ownership.details: '替换渲染资源前,先停止视图的帧循环,并等待使用这些资源的 GPU 工作完成,再释放旧资源。只有当所有视图都已释放该上下文对应的呈现资源,且应用程序通过它创建的资源也已全部释放后,才能释放上下文。'
concepts.platforms.ownership.guidance: '共享的 {frameSchedulerCs} 通过视图的 UI 调度器运行帧处理程序。处理程序应集中于场景数据更新和命令录制,其中耗时的 CPU 工作也会延迟界面响应。'
concepts.platforms.ownership.title: '应用程序与控件的责任'
concepts.platforms.surface.description: '{link}使用 Silk.NET 创建窗口并处理事件。Zenith.NET 通过 {surface} 描述获取原生窗口句柄与尺寸,再据此创建 {swapChain}。操作系统窗口仍由应用程序负责管理。'
concepts.platforms.surface.description.link: '三角形教程'
-concepts.platforms.surface.details: '原生句柄必须与所选后端匹配:'
+concepts.platforms.surface.details: '原生句柄取决于图形 API 和窗口系统。常见组合如下:'
concepts.platforms.surface.guidance: '{appCs} 中的示例宿主支持 Windows、macOS 和 X11。Linux 窗口提供 Xlib 句柄,因此在 Wayland 会话中需要 XWayland。原生 Wayland 应用程序则通过 {surfaceWayland} 提供显示与表面句柄。'
concepts.platforms.surface.table.android.backend: 'Android 上的 Vulkan。'
concepts.platforms.surface.table.apple.backend: 'Apple 平台上的 Metal。'
-concepts.platforms.surface.table.headings.backend: '后端与平台'
+concepts.platforms.surface.table.headings.backend: '图形 API 与平台'
concepts.platforms.surface.table.headings.factory: '呈现目标工厂方法'
concepts.platforms.surface.table.headings.handles: '宿主提供的句柄'
-concepts.platforms.surface.table.wayland.backend: '带有原生 Wayland 宿主的 Vulkan。'
+concepts.platforms.surface.table.wayland.backend: 'Vulkan,使用原生 Wayland 窗口。'
concepts.platforms.surface.table.wayland.handles: 'Wayland 显示与表面'
concepts.platforms.surface.table.win32.backend: 'Windows 上的 DirectX 12 或 Vulkan。'
-concepts.platforms.surface.table.xlib.backend: 'Linux 上带有 X11 或 XWayland 的 Vulkan。'
+concepts.platforms.surface.table.xlib.backend: 'Linux 上的 Vulkan,使用 X11 或 XWayland。'
concepts.platforms.surface.table.xlib.handles: 'X11 显示与窗口'
concepts.platforms.surface.title: '原生呈现目标'
concepts.platforms.title: '平台集成'
concepts.resources.allocation.context: '放置在堆中的资源在整个生命周期内都依赖堆的存储。最后一次 GPU 使用完成后,应先释放资源,再释放堆。'
concepts.resources.allocation.description: '应用程序需要自行管理内存分配时,可以使用 {heap}。堆为资源提供存储,应用程序选择明确的字节偏移量来放置资源,并记录各区域的占用情况。'
-concepts.resources.allocation.details: '对每个资源,使用创建时所需的缓冲区或纹理描述调用 {contextGetSizeAndAlignment}。按返回的大小预留空间,起始偏移量须为返回对齐值的整数倍,且整个区域位于堆内,不与其他仍有效的分配重叠。纹理可能包含后端特有的填充,因此不能仅根据像素数量和每像素字节数计算分配大小。'
+concepts.resources.allocation.details: '对每个资源,使用创建时所需的缓冲区或纹理描述调用 {contextGetSizeAndAlignment}。按返回的大小预留空间,起始偏移量须为返回对齐值的整数倍,且整个区域位于堆内,不与其他仍有效的分配重叠。纹理分配可能含有填充,因此不能仅根据像素数量和每像素字节数计算分配大小。'
concepts.resources.allocation.guidance: '放置在堆中的缓冲区必须使用与堆相同的驻留设置。纹理存储使用 GPU 专用堆。'
concepts.resources.allocation.title: '堆分配'
concepts.resources.bufferUsages.table.constant.role: '通过常量缓冲区绑定读取的着色器参数。'
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: '上传将 CPU 数据复制到 GPU 资
concepts.resources.transfers.details: '调用这些方法前,先处理与其他队列访问之间的冲突。方法内部的等待只覆盖其自身的传输,不会建立与其他队列的依赖。直接通过映射内存复制时,则完全由调用方负责等待存在冲突的 GPU 访问。'
concepts.resources.transfers.guidance: '要将传输与其他 GPU 工作一同提交,可通过 {commandBufferUpload} 或 {commandBufferDownload} 录制。上传源与回读目标的内存生命周期要求不同:'
concepts.resources.transfers.item: '上传调用期间,库会将源数据复制到内部的临时上传存储,即暂存内存。GPU 随后从这块存储读取,因此应用程序的源指针只需保持有效到调用返回。'
-concepts.resources.transfers.notes: '纹理传输中的行步幅是 CPU 数据相邻两行之间的字节距离;切片步幅则是相邻深度切片之间的字节距离。传输操作根据这些值,在 CPU 数据与纹理的 GPU 存储之间复制内容。GPU 完成与数据送达回读目标为何是两个步骤,见{link}。'
-concepts.resources.transfers.notes.link: '同步'
+concepts.resources.transfers.layouts: '录制纹理传输命令不会自动处理布局转换。上传要求 {copyDst} 布局,回读要求 {copySrc} 布局。应在复制之前录制向相应布局的转换,并在复制之后转换到下一次使用所需的布局。'
+concepts.resources.transfers.notes: '纹理传输中的行步幅是 CPU 数据相邻两行之间的字节距离;切片步幅则是相邻深度切片之间的字节距离。传输操作根据这些值,在 CPU 数据与纹理的 GPU 存储之间复制内容。'
concepts.resources.transfers.table.bufferDownload.transfer: '对于 {cpuReadOnly},直接从映射内存复制;否则向传输队列提交回读,并等待完成。'
concepts.resources.transfers.table.bufferUpload.transfer: '对于 {cpuWriteOnly},直接复制到映射内存;否则向传输队列提交上传,并等待完成。'
concepts.resources.transfers.table.headings.method: '方法'
concepts.resources.transfers.table.headings.transfer: '传输行为'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: '将复制及其纹理转换提交到图形队列,并等待完成。操作结束后,所选子资源处于指定的最终布局。'
-concepts.resources.transfers.title: '立即传输与命令录制'
+concepts.resources.transfers.title: '即时传输与命令缓冲区传输'
concepts.resources.usages.description: '{bufferUsages} 和 {textureUsages} 是用于声明资源用途的标志枚举,分别设置在 {bufferDescUsages} 和 {textureDescUsages} 中。资源需要承担多种用途时,可通过 {value} 组合相应成员。'
concepts.resources.usages.title: '资源用途'
-concepts.resources.views.description: '{bufferView} 描述缓冲区的一块区域及其数据解释方式。{textureView} 选择子资源范围,以及兼容的纹理类型和格式。二者都引用已有存储,并遵循创建该存储时声明的用途。视图范围用于描述访问范围,各后端并不因此提供一致的着色器边界检查。'
+concepts.resources.views.description: '{bufferView} 描述缓冲区的一块区域及其数据解释方式。{textureView} 选择子资源范围,以及兼容的纹理类型和格式。二者都引用已有存储,并遵循创建该存储时声明的用途。视图范围描述访问区域,但不能保证不同实现中的着色器越界检查一致。'
concepts.resources.views.details: '资源自身的句柄提供默认视图。需要其他区域或兼容的解释方式时,再创建独立视图。视图及其底层资源都必须保留到 GPU 使用结束;仅持有资源句柄不能使任一对象保持存活。替换其中任一对象时,还须更新包含旧{link}的常量。'
concepts.resources.views.details.link: '资源句柄'
concepts.resources.views.title: '视图与底层资源'
concepts.shaders.binding.context: '计算示例将 {inputTextureSampledHandle} 写入 {input},将 {outputTextureStorageHandle} 写入 {output}。在 Slang 中,{descriptorHandle} 的类型参数规定了着色器访问资源的方式:'
concepts.shaders.binding.description: '{setConstantBuffer} 选择已有缓冲区及字节偏移量,当前管线从该位置读取常量。着色器使用这些参数前,先将数据上传到相应存储。如果此前提交的 GPU 工作仍在读取同一批字节,须等待该工作完成后再更新。'
concepts.shaders.binding.details: '准备好命令缓冲区、计算管线、已填入数据的常量缓冲区和线程组数量后,按以下顺序录制分派。常量缓冲区的绑定作用于当前管线,因此必须先选择管线:'
-concepts.shaders.binding.guidance: '这里,{commandBuffer} 使用 {computePipeline} 及 {constantBuffer} 中的参数录制分派。缓冲区需要声明 {bufferUsagesConstant} 用途,偏移量 0 选择其起始位置。如果多条常量记录共用缓冲区,每条记录的起始偏移量还须满足后端绑定的对齐要求,这与记录内部的字段布局是两项独立要求。'
-concepts.shaders.binding.notes: '{resourceHandle} 包含两个 32 位字段,含义由后端解释,其值仅在创建资源的上下文中有效。'
+concepts.shaders.binding.guidance: '常量缓冲区需要声明 {bufferUsagesConstant} 用途。如果多条常量记录共用缓冲区,每条记录的起始偏移量必须满足绑定对齐要求;这与记录内部的字段布局是两项独立要求。'
+concepts.shaders.binding.notes: '{resourceHandle} 包含两个 32 位字段,具体含义取决于所选图形 API 的实现;其值仅在创建资源的上下文中有效。'
concepts.shaders.binding.reference: '保留资源及用于获取句柄的视图,直到着色器完成最后一次访问。替换纹理或视图后,应更新仍含旧句柄的常量。相关所有权规则见{link}。'
concepts.shaders.binding.reference.link: '资源管理'
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: '读取着色器类型 {t} 的结构化元素'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: '纹理采样状态'
concepts.shaders.binding.table.textureSampledHandle.access: '纹理读取'
concepts.shaders.binding.table.textureStorageHandle.access: '存储纹理的读写'
concepts.shaders.binding.title: '常量缓冲区与资源句柄'
-concepts.shaders.compilation.description: '{zenithCompiler} 将指定的 Slang 入口点编译为 {shaderDesc}。上下文的 {graphicsApi} 决定目标格式:DirectX 12 使用 DXIL,Metal 使用 Metal 库,Vulkan 使用 SPIR-V。'
+concepts.shaders.compilation.description: '{zenithCompiler} 编译 Slang 入口点并返回 {shaderDesc}。上下文的 {graphicsApi} 决定输出格式:DirectX 12 对应 {dxil},Metal 对应 {metallib},Vulkan 对应 {spirv}。'
concepts.shaders.compilation.details: '创建名为 {context} 的图形上下文后,可以编译已复制到可执行文件所在目录的三角形着色器:'
concepts.shaders.compilation.guidance: '入口点名称 {vSMain} 必须与着色器文件中的函数声明一致。在初始化阶段编译着色器并创建管线,渲染期间复用管线。管线创建完成后即可释放着色器对象,具体见{link}。'
concepts.shaders.compilation.guidance.link: '第一个三角形'
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: '对于顶点输入,{inputLayout} 描述
concepts.shaders.layout.details: '常量缓冲区存放着色器参数,结构化缓冲区存放指定类型的元素数组。它们的布局由 Slang 声明决定,不使用 {inputLayout}。C# 字段偏移量、元素大小和填充必须与编译后的着色器布局一致。即使某个 C# 类型是非托管类型,可以直接按字节复制,其内存排列也未必符合着色器要求;例如,顶点中紧密排列的 {float3},在着色器缓冲区中可能需要不同的对齐方式。'
concepts.shaders.layout.guidance: '着色器参数除了普通数值,也可以包含资源句柄。句柄标识的是已有存储,因此将句柄复制到常量缓冲区并不会复制资源内容。'
concepts.shaders.layout.notes: '{computeShaderSlang} 中对应的声明为:'
-concepts.shaders.layout.reference: '两个尺寸值占用前 8 字节,后面是两个各占 8 字节的句柄。C# 示例为整条记录预留 256 字节。其他记录的大小应根据各自字段以及所需的布局和对齐方式确定。'
+concepts.shaders.layout.reference: 'C# 字段占用前 24 字节:两个尺寸值合计 8 字节,每个句柄各占 8 字节。整条记录预留 256 字节,其余字节用于填充。其他参数块的字段偏移量也必须与着色器布局匹配。如果多条记录共用缓冲区,还需在记录之间留出足够的填充,以满足绑定对齐要求。'
concepts.shaders.layout.title: '数据布局'
concepts.shaders.matrices.description: '编译器采用行优先的矩阵存储方式,使同一行的元素连续排列。{link}在偏移量 0、64 和 128 处保存三个 {matrix4x4} 值,其{detail}按模型、视图和投影顺序执行 {mulVectorMatrix}。'
concepts.shaders.matrices.description.detail: '着色器'
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: '旋转立方体渲染器'
concepts.shaders.matrices.details: '存储顺序决定矩阵元素在内存中的排列,乘法顺序决定变换。C# 与 Slang 应采用相互匹配的约定。'
concepts.shaders.matrices.title: '矩阵约定'
concepts.shaders.title: '着色器数据与绑定'
-concepts.synchronization.backends.description: 'DirectX 12 和 Vulkan 将纹理转换记录为布局与访问状态的变化。在 Zenith.NET 的 Metal 后端中,{transition} 没有对应的 GPU 操作。Metal 后端将命令组织为渲染与计算编码器,并在编码器结束时插入可见性屏障。同一编码器内存在依赖的操作,例如连续的计算分派,通过显式调用 {barrier} 协调。'
-concepts.synchronization.backends.details: '{link}开始图形渲染通道时,会结束计算编码器,使计算输出对后续图形工作可见。连续两次计算分派仍位于同一编码器内,即使中间录制了纹理转换,也需要屏障来处理依赖。因此,可跨后端使用的命令序列既要考虑纹理布局,也要处理访问之间的依赖。'
+concepts.synchronization.backends.description: 'DirectX 12 和 Vulkan 将纹理转换记录为布局与访问状态的变化。在 Zenith.NET 的 Metal 实现中,{transition} 没有对应的 GPU 操作。该实现将命令组织为渲染编码器和计算编码器,并在编码器结束时插入可见性屏障。同一编码器内存在依赖的操作,例如连续的计算分派,则通过显式调用 {barrier} 协调。'
+concepts.synchronization.backends.details: '{link}开始图形渲染通道时,会结束计算编码器,使计算输出对后续图形工作可见。连续两次计算分派仍位于同一编码器内,即使中间录制了纹理转换,也需要屏障来处理依赖。'
concepts.synchronization.backends.details.link: '计算示例'
-concepts.synchronization.backends.title: '后端行为'
+concepts.synchronization.backends.title: '不同图形 API 下的同步行为'
concepts.synchronization.barriers.context: '选择包含相关访问、且受到当前队列支持的阶段。{barrierStagesAll} 涵盖所有受支持的阶段;若依赖只涉及其中一部分,可选择更小的范围。'
concepts.synchronization.barriers.description: '假设同一个命令缓冲区内有两次计算分派,第一次写入模拟数据,第二次读取这些数据。在两次分派之间设置屏障,让第二次分派读到已经完成的写入结果。对于存储缓冲区,这样即可安排访问顺序,无须进行纹理布局转换:'
concepts.synchronization.barriers.details: '第一个参数指定产生数据的阶段,第二个参数指定使用数据的阶段。二者共同描述两次分派之间所需的执行顺序和内存可见性。'
-concepts.synchronization.barriers.guidance: '{link}在模拟步骤之间采用这一方式。每道屏障都位于产生数据的分派之后、使用数据的分派之前。'
+concepts.synchronization.barriers.guidance: '{link}在模拟步骤之间采用这一方式。'
concepts.synchronization.barriers.guidance.link: 'FluidTank 模拟'
concepts.synchronization.barriers.title: '管线屏障'
concepts.synchronization.dependencies.description: '逐个资源确认哪些访问涉及同一份数据。只要其中存在写入,就必须维持所需的先后顺序。两次读取本身没有冲突,但仍需满足纹理布局和呈现要求。CPU 更新数据或释放资源前,也须等待 GPU 完成对相应存储的使用。'
concepts.synchronization.dependencies.details: '应根据操作执行的位置选择机制:'
-concepts.synchronization.dependencies.guidance: '一项工作可能同时需要多种同步机制。例如,纹理由另一队列生成时,除了提交依赖,还需为下一次使用设置正确的布局。这两项操作本身都不需要阻塞 CPU;只有 CPU 要访问或释放相关数据时,才需要在 CPU 端等待。'
+concepts.synchronization.dependencies.guidance: '一个队列写入的纹理被另一队列使用时,应在提交之间建立依赖,并录制所需的布局转换。这两步不会阻塞 CPU。CPU 要访问数据或释放资源前,才需等待相应工作完成。'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: '对相关的完成值调用 {wait}。'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'CPU 访问或资源释放需要等待 GPU 完成'
concepts.synchronization.dependencies.table.crossQueue.mechanism: '将生产者的 {timelineValue} 传给消费者的 {submit}。'
@@ -256,7 +254,7 @@ home.entries.reference.category: '参考'
home.entries.reference.description: '查阅 API 类型、成员与声明'
home.entries.reference.title: 'API 参考'
home.entries.samples.action: '浏览示例'
-home.entries.samples.category: '示例'
+home.entries.samples.category: '代码示例'
home.entries.samples.description: '图形与计算技术的可运行示例'
home.entries.samples.title: '示例'
home.entries.title: '文档'
@@ -265,14 +263,14 @@ home.entries.tutorial.category: '教程'
home.entries.tutorial.description: '从空项目开始,绘制第一个三角形'
home.entries.tutorial.title: '第一个三角形'
home.introduction.accent: '跨平台图形开发'
-home.introduction.description: 'Zenith.NET 提供统一的图形与计算 API,支持 DirectX、Metal 和 Vulkan'
+home.introduction.description: 'Zenith.NET 提供统一的图形与计算 API,支持 DirectX 12、Metal 4 和 Vulkan 1.4'
home.introduction.title: '面向 .NET 的{lineBreak}{accent}'
-home.meta.description: '使用 Zenith.NET 开发跨平台图形与计算应用,通过统一 API 使用 DirectX、Metal 和 Vulkan'
+home.meta.description: '使用 Zenith.NET 开发跨平台图形与计算应用,通过统一 API 使用 DirectX 12、Metal 4 和 Vulkan 1.4'
home.scene.description: '可交互的旋转几何体。拖动或使用方向键调整视角。'
home.scene.label: '几何体显示'
home.scene.surface: '表面'
home.scene.wireframe: '线框'
-home.title: '适用于 .NET 的现代 RHI'
+home.title: '面向 .NET 的现代 RHI'
learning.concepts.description: '选择资源用途、描述着色器数据与协调 GPU 执行'
learning.concepts.execution.description: '命令录制、提交与资源生命周期'
learning.concepts.platforms.description: '原生呈现与 UI 渲染控件'
@@ -290,71 +288,65 @@ learning.title: '学习'
reference.description: '资源、命令与平台集成的参考文档'
reference.entries.commands.description: '图形、计算与传输命令'
reference.entries.commands.label: '录制命令'
-reference.entries.context.description: '为所选后端创建 GPU 资源'
+reference.entries.context.description: '通过图形上下文创建 GPU 资源'
reference.entries.context.label: '从这里开始'
reference.meta.description: 'Zenith.NET 的命名空间、类型与成员'
reference.navigation.core: '核心 API 参考'
reference.title: 'API 参考'
-samples.computeShader.description: '示例加载 {assetsTexturesShokoPng},通过一次计算分派将图像转换为灰度,再显示输出纹理。转换只执行一次,后续帧显示相同结果。渲染器展示了采样纹理与可写纹理的绑定、向上取整线程组数量以覆盖整张图像的计算方式,以及着色器中的图像边界检查。'
+samples.computeShader.description: '计算着色器将彩色图像转换为灰度图,展示 GPU 图像处理。'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: '计算着色器'
-samples.cube.description: '旋转立方体加入索引绘制、常量缓冲区中的模型、视图和投影矩阵,以及深度测试。窗口大小变化时,会重建 {d32FloatS8UInt} 深度/模板纹理。'
+samples.cube.description: '通过旋转立方体展示索引绘制、三维变换和深度测试。'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: '旋转立方体'
-samples.description: '每个示例均由 C# 渲染器与 Slang 着色器组成,集中说明一项技术。完整的应用程序设置与渲染顺序见{link}。'
-samples.description.link: '第一个三角形'
+samples.description: '这些示例涵盖渲染与计算,从单个三角形到交互式应用和诊断工具。'
samples.execution.description: '运行 {link} 项目,并从控制台菜单选择示例。'
samples.execution.description.link: 'ZenithTutorials'
samples.execution.title: '运行示例'
-samples.host.description: '{appCs} 初始化上下文、窗口和交换链。每帧获取命令缓冲区,调用所选渲染器,提交命令并呈现结果。{iRendererCs} 规定渲染器的更新、渲染、调整大小和释放操作。'
-samples.host.details: '计算与光线追踪渲染器生成离屏纹理。{texturePresenterCs} 和 {presentTextureSlang} 将这些纹理绘制到当前输出纹理,随后由共享宿主提交命令并呈现这一帧。'
-samples.host.title: '宿主与呈现'
-samples.indirectDrawing.description: '间接绘制通过索引绘制参数缓冲区和保存各实例数据的结构化缓冲区,绘制多个立方体。CPU 提供绘制参数并更新变换。'
+samples.indirectDrawing.description: '以网格状排列、独立旋转的彩色立方体,展示使用绘制参数缓冲区的间接绘制。'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: '间接绘制'
-samples.meshShading.description: '任务着色器剔除球体实例,将保留的索引传给负责生成几何体的网格着色器。创建管线前,渲染器检查 {contextCapabilitiesMeshShadingSupported}。'
+samples.meshShading.description: '此示例使用任务着色器与网格着色器绘制彩色球体阵列,并跳过相机视野外的球体。需要网格着色支持。'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: '网格着色'
-samples.rayTracing.description: '该示例为地面和程序化球体构建底层与顶层加速结构,再在计算着色器中执行内联光线查询。初始化前检查 {contextCapabilitiesRayTracingSupported}。'
+samples.rayTracing.description: '此示例通过光线查询绘制具有反射效果的球体,以及它们在棋盘格地面上的阴影。需要光线追踪支持。'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: '光线追踪'
samples.title: '示例'
-samples.triangle.description: '三角形示例将顶点缓冲区与对应的输入布局关联,通过图形管线绘制三个顶点。'
+samples.triangle.description: '用一个三角形展示基础图形管线,颜色在三个顶点之间平滑过渡。'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: '完整教程'
samples.triangle.title: 'Hello Triangle'
-samples.workloads.description: '主仓库的{link}包含规模较大的应用程序,这些项目直接引用库源码。'
+samples.workloads.description: 'Zenith.NET 仓库的 {link} 包含以下应用与工具。'
samples.workloads.description.link: 'Experiments 目录'
-samples.workloads.details: '窗口实验项目采用相同的 Windows、macOS 和 Linux/X11 呈现路径。Avalonia、WinForms、WPF、WinUI/Uno 和 MAUI 控件的帧生命周期及实现代码见{link}。'
-samples.workloads.details.link: '平台集成'
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: 'CornellBox'
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '路径追踪、降噪、色调映射、分辨率放大和 ImGui 控件。需要光线追踪支持。'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '用于观察光照与反射效果的交互式室内场景。需要光线追踪支持。'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: 'FluidTank'
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '计算流体模拟、模拟阶段之间的依赖,以及多通道表面渲染。'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '模拟水在水箱中的运动,提供水体和粒子两种显示方式。'
samples.workloads.table.headings.example: '示例'
-samples.workloads.table.headings.whatItDemonstratesAndRequires: '技术与运行要求'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: '简介'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: 'InkCanvas'
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '原生窗口中的 Skia 绘制与输入处理。需要对应目标平台的后端和 Skia 原生库。'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '支持自由绘制和擦除笔画的画布。'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: 'PlatformDetection'
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '尝试为每个后端创建上下文,并报告设备能力。创建失败时显示为不支持,原因可能是设备、驱动程序或缺失的运行时依赖。'
-samples.workloads.title: '综合应用'
-tutorial.context.description: '{graphicsContext} 通过所选后端连接应用程序与 GPU,并提供创建渲染资源的方法。'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '在控制台中显示图形 API 的可用情况及设备支持的功能。'
+samples.workloads.title: '应用与工具'
+tutorial.context.description: '{graphicsContext} 让应用程序通过所选图形 API 使用 GPU,并提供创建渲染资源的方法。'
tutorial.context.details: '在{emphasis}插入上下文初始化代码:'
tutorial.context.details.emphasis: 'using 指令之后、{iWindowWindow} 之前'
-tutorial.context.guidance: '各分支为当前平台选择后端并请求启用验证。{validationMessage} 消息会输出到控制台。'
+tutorial.context.guidance: '各分支为所用图形 API 请求启用验证。处理程序将通过 {validationMessage} 报告的诊断消息输出到控制台。'
tutorial.context.imports: '在 {programCs} 顶部添加以下 using 指令:'
tutorial.context.title: '图形上下文'
tutorial.description: '本教程从一个空的 .NET 控制台项目开始,逐步完成窗口创建,并在窗口中绘制一个彩色三角形。'
tutorial.details: '本教程有三个检查点:空窗口、单色背景和彩色三角形。每完成一个检查点,先运行程序确认结果,再继续添加下一部分。'
tutorial.draw.context: '{draw} 的参数如下:'
tutorial.draw.description: '在 {windowRender} 回调中,用以下命令替换 {addTheTriangleDrawCommandsHereLater},位置保持在 {beginRenderPass} 与 {endRenderPass} 之间:'
-tutorial.draw.details: '{setPipeline} 选择着色器和渲染状态。后端按管线的输入布局解释顶点绑定,因此这一步必须先于顶点绑定。'
+tutorial.draw.details: '{setPipeline} 选择着色器和渲染状态。管线的输入布局决定如何读取顶点数据,因此必须先设置管线,再绑定顶点缓冲区。'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} 从缓冲区的字节偏移 0 开始,将已上传的顶点数据绑定到输入槽 0,对应 {inputLayouts} 中唯一的条目。'
-tutorial.draw.notes: '这些调用录制绘制命令。已有的 {submitWait} 提交命令并等待 GPU 完成,随后 {present} 请求显示完成的图像。保留通道开始时的清除操作,让三角形以外的区域也有确定的背景色。'
+tutorial.draw.notes: '保留通道开始时的清除操作,让三角形以外的区域也有确定的背景色。'
tutorial.draw.table.firstInstance.meaning: '实例编号从零开始。'
tutorial.draw.table.firstVertex.meaning: '从缓冲区中的第一个顶点开始。'
tutorial.draw.table.headings.argument: '参数'
@@ -370,25 +362,25 @@ tutorial.execution.title: '运行应用程序'
tutorial.frame.commands.context: '{endRenderPass} 之后的第二次转换使输出纹理进入可呈现的布局。{submit} 结束录制并提交命令缓冲区,{wait} 阻塞至本次提交完成,随后 {present} 请求显示渲染结果。'
tutorial.frame.commands.description: '渲染通道将写入同一组附件的绘制操作组织在一起。本通道用交换链的输出纹理接收颜色输出。{colorAttachmentClear} 指定以 RGBA 颜色初始化该附件,并在通道结束时保留内容。{beginRenderPass} 按这些设置录制通道的开始命令。'
tutorial.frame.commands.details: '集合中有一个颜色附件。{null} 表示本通道不使用深度/模板附件。'
-tutorial.frame.commands.guidance: '{beginRenderPass} 默认让视口和裁剪区域覆盖整个附件。视口把渲染坐标映射为像素位置,裁剪区域则限制可以写入的范围。'
+tutorial.frame.commands.guidance: '{beginRenderPass} 默认让视口和裁剪区域覆盖整个附件。视口把渲染坐标映射为像素位置,裁剪区域则限制绘制可写入的像素范围。'
tutorial.frame.commands.title: '清除、提交与呈现'
-tutorial.frame.description: '先把窗口填成一种背景色,这个操作称为清除。背景正常显示后,就说明呈现目标、命令提交和呈现流程已经接通,可以继续加入三角形的顶点和着色器。'
-tutorial.frame.details: 'Silk.NET 在需要绘制一帧时调用渲染回调。本示例不使用回调传入的时间间隔,因此将该参数命名为 {value}。在{emphasis}注册回调:'
+tutorial.frame.description: '先用一种背景色填满窗口,这称为清除。若颜色正常显示,说明命令提交和画面呈现已生效。接下来再加入三角形的顶点和着色器。'
+tutorial.frame.details: 'Silk.NET 在需要绘制一帧时调用渲染回调。在{emphasis}注册回调:'
tutorial.frame.details.emphasis: '{windowRun} 之前'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} 返回可直接录制的命令缓冲区。录制描述 GPU 工作,提交后才开始执行。'
-tutorial.frame.target.details: '纹理布局描述操作对纹理的访问方式。第一次 {transition} 将输出纹理准备为颜色附件。这里的 {default} 选择 mip 级别 0 和数组层 0,也就是输出纹理的基础图像。由于这个通道会清除整张图像,可以指定 {undefined},允许丢弃原有内容。'
+tutorial.frame.target.description: '命令队列接收已录制的工作,交由 GPU 执行。{graphicsQueueCommandBuffer} 从图形队列取得一个已开始录制的命令缓冲区。录制描述 GPU 要执行的工作,提交后才开始执行。'
+tutorial.frame.target.details: '纹理布局描述操作对纹理的访问方式。第一次 {transition} 将输出纹理准备为颜色附件。这里的 {default} 选择 mip 级别 0 和数组层 0,也就是输出纹理的基础子资源。由于这个通道会清除整张图像,可以指定 {undefined},允许丢弃原有内容。'
tutorial.frame.target.guidance: '呈现后可能换用另一张图像,因此每一帧都要获取当前的输出纹理。'
tutorial.frame.target.title: '准备输出纹理'
tutorial.frame.title: '第一帧'
tutorial.geometry.data.description: '在{emphasis}添加顶点数组。后续资源初始化也放在该回调之前,顺序如下。'
tutorial.geometry.data.description.emphasis: '{windowRender} 之前'
-tutorial.geometry.data.details: '每个条目构造一个 {vertex},内部的两个 {new} 表达式分别提供 {vector3} 位置和 {vector4} 颜色。三个位置对应上角、右下角和左下角。顶点着色器将 {w} 作为第四个位置坐标;w 为 1 时,x、y 也就是归一化设备坐标,-1 与 +1 对应图像边界,0 对应中心,与像素尺寸无关。'
+tutorial.geometry.data.details: '三个位置分别构成三角形的上角、右下角和左下角。本例中,x、y 在图像内的范围都是 -1 到 +1:0 对应中心,x 的正方向向右,y 的正方向向上。'
tutorial.geometry.data.guidance: '每个颜色包含红、绿、蓝和 alpha 分量,alpha 设为 1。三个顶点的 z 坐标均为 0,位于同一平面。'
tutorial.geometry.data.title: '顶点位置与颜色'
tutorial.geometry.description: '三角形的每个顶点都有位置和颜色。GPU 根据三个位置确定三角形的形状,再对顶点颜色插值,得到内部各处的颜色。'
tutorial.geometry.format.description: '在{emphasis}追加顶点声明:'
tutorial.geometry.format.description.emphasis: '{programCs} 的末尾、清理语句之后'
-tutorial.geometry.format.details: '{file} 将类型的使用范围限定在 {programCs} 内,{layoutKindSequential} 则保留字段的声明顺序。{position} 包含三个 32 位浮点数,字节偏移量为 0;{color} 包含四个,字节偏移量为 12。因此,每个顶点占 28 字节。稍后将通过输入布局描述这一排列,让 GPU 正确读取各字段。'
+tutorial.geometry.format.details: '{layoutKindSequential} 保留字段的声明顺序。{position} 包含三个 32 位浮点数,字节偏移量为 0;{color} 包含四个,字节偏移量为 12。因此,每个顶点占 28 字节。输入布局将描述这一排列,让 GPU 正确读取各字段。'
tutorial.geometry.format.imports: '在 {programCs} 顶部添加以下 using 指令,以使用向量类型和结构体布局特性:'
tutorial.geometry.format.title: '顶点表示'
tutorial.geometry.title: '顶点数据'
@@ -397,8 +389,7 @@ tutorial.geometry.upload.description: '将顶点存入 {buffer},供 GPU 在绘
tutorial.geometry.upload.details: '分配大小为 {sizeofVertexVerticesLength},即三个 28 字节顶点,共 84 字节。{bufferUsagesVertex} 声明顶点输入用途,{cpuWriteOnly} 允许 CPU 直接初始化。描述中的步幅记录元素大小,随后定义的输入布局指定 GPU 如何读取各个顶点属性。'
tutorial.geometry.upload.guidance: '分配不会初始化缓冲区内容。{upload} 使用数据描述中的源指针和字节数,将数组复制到目标字节偏移量 0。'
tutorial.geometry.upload.imports: '在 {programCs} 顶部的 using 指令中添加 {bufferAlias},以区分 Zenith.NET 的缓冲区类型与 {systemBuffer}。'
-tutorial.geometry.upload.notes: '在 {programCs} 末尾的清理代码中,紧接在 {swapChainDispose} 之前加入 {vertexBufferDispose}。较大静态几何体所需的 GPU 专用存储与上传方式见{link}。'
-tutorial.geometry.upload.notes.link: '资源管理'
+tutorial.geometry.upload.notes: '在 {programCs} 末尾的清理代码中,紧接在 {swapChainDispose} 之前加入 {vertexBufferDispose}。'
tutorial.geometry.upload.title: '缓冲区分配与上传'
tutorial.input.description: 'GPU 需要知道位置、颜色等顶点属性存在哪里。输入布局指定每个属性的格式和字节偏移量,并用步幅表示从一个顶点到下一个顶点相隔多少字节。在创建着色器之后添加以下代码:'
tutorial.input.details: '{inputLayoutAdd} 将每个属性追加在前一个属性之后,并将其大小计入步幅。偏移量根据这里提供的格式计算,而非通过检查 C# 结构体获得。这两个字段对应的布局如下:'
@@ -413,14 +404,12 @@ tutorial.input.table.nextVertex.shaderInput: '下一个输入记录'
tutorial.input.table.vertexColor.format: '{float4}(16 字节)'
tutorial.input.table.vertexPosition.format: '{float3}(12 字节)'
tutorial.input.title: '顶点输入布局'
-tutorial.lifecycle.description: '每帧依次执行以下操作:'
-tutorial.lifecycle.details: '关闭窗口后,{run} 返回,程序继续执行清理代码。每一帧都已等待其提交完成,因此现在可以释放这些命令使用的资源。{windowRun} 之后完整的清理代码如下:'
+tutorial.lifecycle.description: '每帧获取当前输出纹理,将其转换为渲染所需的布局,清除背景并绘制三角形;再转换为呈现布局,提交命令、等待完成并呈现。'
+tutorial.lifecycle.details: '关闭窗口后,{run} 返回,程序继续执行清理代码。渲染回调已等待每帧提交的工作完成,因此现在可以释放这些命令使用的资源。{windowRun} 之后完整的清理代码如下:'
tutorial.lifecycle.guidance: '先释放交换链,再销毁其原生窗口;先释放应用程序资源,再释放上下文。已提交的命令缓冲区由队列回收,输出纹理由交换链管理,二者都不需要单独调用 {dispose}。'
-tutorial.lifecycle.title: '帧生命周期与清理'
tutorial.pipeline.behavior: '在输入布局之后创建管线:'
tutorial.pipeline.context: '{cullNone} 关闭面剔除,因此无论顶点在画面中呈顺时针还是逆时针排列,三角形都会被绘制。'
tutorial.pipeline.description: '{graphicsPipeline} 将顶点布局、两个着色器,以及图元组装和附件输出所需的设置组合在一起。'
-tutorial.pipeline.details: '着色器负责处理顶点和片元。其余管线设置决定图元如何组装、是否剔除某个朝向的面,以及如何进行深度测试和颜色混合:'
tutorial.pipeline.guidance: '管线颜色格式必须匹配渲染通道附件,因此直接取自 {swapChainDescFormat}。{count1} 表示每像素一个采样点。'
tutorial.pipeline.item: '{triangleList} 将每组连续的三个顶点组装成一个三角形。'
tutorial.pipeline.notes: '{depthNone} 关闭深度测试和深度写入,与通道没有深度附件的配置一致。'
@@ -428,28 +417,25 @@ tutorial.pipeline.reference: '{opaque} 关闭混合,因此片元着色器输
tutorial.pipeline.title: '图形管线'
tutorial.pipeline.usage: '管线创建完成后即可释放着色器对象。渲染期间保留管线,在清理代码中将 {pipelineDispose} 放在 {vertexBufferDispose} 之前。'
tutorial.presentation.title: '图形上下文与呈现'
-tutorial.project.context: '在项目构建设置中启用{emphasis}({allowUnsafeBlocks})。窗口辅助代码的原生调用和顶点上传需要不安全代码。'
+tutorial.project.context: '在项目构建设置中启用{emphasis}({allowUnsafeBlocks})。窗口辅助类中的原生调用和顶点上传需要不安全代码。'
tutorial.project.context.emphasis: '允许不安全代码'
tutorial.project.description: '创建名为 {firstTriangle} 的 C# 控制台项目,目标框架设为 .NET 10。'
tutorial.project.details: '为项目添加以下 NuGet 包:'
-tutorial.project.guidance: '{zenithNET} 提供统一渲染 API,三个后端包提供各平台的实现。{zenithNETCompiler} 为所选后端编译稍后介绍的 Slang 着色器。Silk.NET 负责窗口创建与事件处理。'
+tutorial.project.guidance: '{zenithNET} 提供共用的图形与计算 API,三个图形 API 包分别实现它。{zenithNETCompiler} 为所选 API 编译 Slang 着色器。'
tutorial.project.title: '项目设置'
-tutorial.requirements.context: '{link}及其{detail}提供了本教程的参考实现。'
-tutorial.requirements.context.detail: '共享宿主'
-tutorial.requirements.context.link: 'Hello Triangle 示例'
-tutorial.requirements.description: '需要 {emphasis},并具备基础 C# 知识。应用程序以 {net10} 为目标框架。GPU 和驱动程序须支持所在平台选用的后端:'
+tutorial.requirements.description: '需要 {emphasis} 和基础 C# 知识。所用 GPU 与驱动程序还须具备下表中的图形能力:'
tutorial.requirements.description.emphasis: '.NET 10 SDK'
-tutorial.requirements.guidance: 'Zenith.NET 渲染到应用程序提供的原生呈现目标。Silk.NET.Windowing 创建窗口并处理事件。macOS 使用由 {cAMetalLayerCs} 表示的 Metal 图层,窗口辅助代码负责将其连接到窗口。'
-tutorial.requirements.table.headings.graphicsBackend: '图形后端'
+tutorial.requirements.guidance: 'Zenith.NET 渲染到应用程序提供的原生呈现目标。Silk.NET.Windowing 创建窗口并处理事件。'
+tutorial.requirements.table.headings.graphicsBackend: '图形能力'
tutorial.requirements.table.headings.platform: '平台'
-tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4'
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 与 VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux(X11 或 XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: 'Metal 4'
tutorial.requirements.table.macOS.platform: 'macOS'
-tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12'
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 与 Shader Model 6.6'
tutorial.requirements.table.windows.platform: 'Windows'
tutorial.requirements.title: '前置条件'
-tutorial.resize.context: '再次构建并运行程序。调整窗口大小后,背景应继续填满整个窗口:每次开始新的渲染通道时,视口和裁剪区域都会按调整后的附件尺寸设置。保留渲染回调,后面将在这个通道内绘制三角形。'
+tutorial.resize.context: '再次构建并运行程序。调整窗口大小后,背景应继续填满整个窗口。保留渲染回调,后面将在这个通道内绘制三角形。'
tutorial.resize.description: '帧缓冲区尺寸变化时,交换链也要随之调整。在渲染回调之后、{windowRun} 之前注册 {framebufferResize} 回调:'
tutorial.resize.details: '这里监听的是以像素为单位的{link},而非窗口逻辑尺寸的变化。窗口最小化时,帧缓冲区的宽度或高度可能变为零;此时,尺寸变化回调保留现有交换链,不执行调整。渲染回调也会在任一尺寸为零时直接返回,直到帧缓冲区恢复有效尺寸后再继续绘制。'
tutorial.resize.details.link: '帧缓冲区大小变化'
@@ -461,51 +447,33 @@ tutorial.shaders.compilation.description: '将 {triangleSlang} 的文件属性{e
tutorial.shaders.compilation.description.detail: '如果较新则复制'
tutorial.shaders.compilation.description.emphasis: '复制到输出目录'
tutorial.shaders.compilation.details: '返回 {programCs},在顶点上传之后、渲染回调之前添加着色器初始化:'
-tutorial.shaders.compilation.guidance: '{zenithCompiler} 为 {contextGraphicsApi} 指定的后端编译源码,{createShader} 再根据编译后的描述创建着色器对象。入口点名称 {vSMain} 和 {fSMain} 分别选中 Slang 文件中定义的两个函数。'
+tutorial.shaders.compilation.guidance: '{zenithCompiler} 按 {contextGraphicsApi} 指定的图形 API 编译源码,{createShader} 再根据编译后的描述创建着色器对象。入口点名称 {vSMain} 和 {fSMain} 分别选中 Slang 文件中定义的两个函数。'
tutorial.shaders.compilation.title: '编译着色器'
tutorial.shaders.context: '{fSInput} 连接两个着色器阶段。顶点着色器将裁剪空间位置写入 {sVPOSITION},GPU 据此判断三角形的可见部分。{cOLOR0} 字段传递顶点颜色,颜色经过三角形内部的插值后到达片元着色器。两个阶段必须使用一致的颜色类型与语义。'
-tutorial.shaders.description: '着色器是在 GPU 上运行的程序。顶点着色器确定每个顶点的位置,片元着色器则确定图像中被覆盖位置的颜色。我们将两个阶段写在同一个 Slang 文件中,并分别定义入口点,也就是各阶段开始执行的函数。'
-tutorial.shaders.details: '创建 {triangleSlang},先定义输入与输出结构:'
+tutorial.shaders.description: '着色器是在 GPU 上运行的程序。顶点着色器确定每个顶点的位置,片元着色器则确定图像中被覆盖位置的颜色。两个阶段写在同一个 Slang 文件中,分别定义入口点,也就是各阶段开始执行的函数。'
+tutorial.shaders.details: '在项目根目录中创建 {triangleSlang},定义以下输入与输出结构:'
tutorial.shaders.fragment.description: '在同一文件中追加片元入口点:'
tutorial.shaders.fragment.details: '光栅化确定三角形在图像中的覆盖范围,并在这些位置生成片元。每个片元的颜色由三个顶点的颜色插值得到。{fSMain} 返回这个颜色,{sVTARGET} 则将结果送到第一个颜色附件。'
tutorial.shaders.fragment.title: '片元着色'
tutorial.shaders.guidance: '{vSInput} 定义顶点着色器输入。{pOSITION0} 和 {cOLOR0} 按语义标识属性,C# 字段名称本身不建立这一映射。'
tutorial.shaders.title: '着色器阶段'
tutorial.shaders.vertex.description: '在 {triangleSlang} 中追加顶点入口点:'
-tutorial.shaders.vertex.details: 'GPU 为每个输入顶点调用这一入口点,补充齐次坐标 {w} 并传递颜色。顶点处理结束后,位置要除以 w。本例 w 为 1,x、y、z 保持不变,可直接解释为归一化设备坐标。'
+tutorial.shaders.vertex.details: 'GPU 为每个输入顶点执行这个函数。函数补充第四个位置分量 {w},并传递颜色。顶点处理结束后,GPU 将 x、y、z 分别除以 w,得到归一化设备坐标。本例 w 为 1,因此这些值保持不变。'
tutorial.shaders.vertex.title: '顶点着色'
tutorial.surface.description: '在{emphasis}指定原生呈现目标:'
tutorial.surface.description.emphasis: '{windowCenter} 之后、{windowRun} 之前'
tutorial.surface.details: '帧缓冲区是窗口用于显示的像素图像。{surface} 描述原生呈现目标及其尺寸,{framebufferSize} 给出以像素为单位的大小。启用显示缩放时,这个大小可能与窗口的逻辑尺寸不同。'
-tutorial.surface.guidance: '呈现目标提供后端所需的原生句柄:Windows 使用 Win32 窗口,Linux 使用 X11 显示与窗口,macOS 使用已连接的 Metal 图层。'
+tutorial.surface.guidance: '呈现目标提供所选图形 API 所需的原生句柄:Windows 使用 Win32 窗口,Linux 使用 X11 显示与窗口,macOS 使用已连接的 Metal 图层。'
tutorial.surface.title: '原生呈现目标'
tutorial.swapChain.context: '交换链同时依赖上下文与窗口。将 {programCs} 末尾的 {windowDispose} 替换为以下释放顺序:'
tutorial.swapChain.description: '紧接呈现目标描述,创建交换链:'
tutorial.swapChain.details: '{swapChain} 管理窗口呈现的图像。{drawable} 以图像资源 {texture} 的形式提供当前图像。渲染后,{present} 请求显示该图像,并推进到下一个输出纹理。'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} 按蓝、绿、红和 alpha 顺序保存四个 8 位通道。{uNorm} 将整数 0–255 对应到 0–1。着色器仍输出逻辑 RGBA 值,格式只规定存储表示;管线通过 {swapChainDescFormat} 匹配附件。'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} 按蓝、绿、红和 alpha 顺序保存四个 8 位通道。{uNorm} 将整数 0–255 对应到 0–1。着色器仍输出逻辑 RGBA 值,格式只规定存储表示。'
tutorial.swapChain.title: '交换链'
tutorial.title: '第一个三角形'
-tutorial.troubleshooting.description: '结合控制台诊断与三个检查点定位失败阶段:'
-tutorial.troubleshooting.details: '{link}与{detail}可用于核对顶点数据、输入布局和绘制操作。该示例将窗口与提交逻辑放入共享宿主,本教程则保留在 {programCs} 中。{context}进一步介绍索引绘制、变换与深度测试。'
-tutorial.troubleshooting.details.context: '旋转立方体'
-tutorial.troubleshooting.details.detail: 'Slang 着色器'
-tutorial.troubleshooting.details.link: '示例渲染器'
-tutorial.troubleshooting.table.backend.check: '检查所选后端是否受设备和已安装的图形驱动程序支持。'
-tutorial.troubleshooting.table.backend.symptom: '后端创建失败'
-tutorial.troubleshooting.table.drawing.check: '检查上传大小、输入布局、管线选择以及渲染通道内绘制命令的位置。'
-tutorial.troubleshooting.table.drawing.symptom: '背景出现但三角形未出现'
-tutorial.troubleshooting.table.headings.check: '检查项'
-tutorial.troubleshooting.table.headings.symptom: '现象'
-tutorial.troubleshooting.table.input.check: '检查步幅是否为 28 字节,位置和颜色是否分别从偏移 0 和 12 字节开始。'
-tutorial.troubleshooting.table.input.symptom: '顶点位置或颜色异常'
-tutorial.troubleshooting.table.shaders.check: '检查复制的 {triangleSlang}、入口点拼写以及编译器报告的诊断信息。'
-tutorial.troubleshooting.table.shaders.symptom: '背景色正常显示,但着色器加载失败'
-tutorial.troubleshooting.table.window.check: '确认 .NET 项目能够构建成功,并且仅包含窗口的步骤可以在桌面会话中运行。在 Linux 上,检查 X11 或 XWayland 是否可用。'
-tutorial.troubleshooting.table.window.symptom: '窗口未打开'
-tutorial.troubleshooting.title: '问题排查'
tutorial.window.description: '将 {cocoaHelperCs} 下载到项目中。该辅助类负责将 Metal 图层连接到 macOS 窗口。'
-tutorial.window.details: '将自动生成的 {programCs} 内容替换为以下代码。它使用顶级语句,按书写顺序执行,不需要显式编写 {main} 方法。后续各节会指出新代码应放在哪里:'
-tutorial.window.guidance: '{graphicsAPINone} 将图形上下文的创建交给 Zenith.NET。{initialize} 创建原生窗口,使窗口系统的句柄可供使用;{center} 把窗口放到屏幕中央。{run} 持续处理事件,直到窗口关闭,随后执行 {dispose} 释放窗口。'
+tutorial.window.details: '将 {programCs} 的内容替换为以下代码:'
+tutorial.window.guidance: '{graphicsAPINone} 告诉 Silk.NET 不创建图形上下文;应用程序稍后会创建 Zenith.NET 上下文。{initialize} 创建原生窗口,使窗口系统的句柄可供使用;{center} 把窗口放到屏幕中央。{run} 持续处理事件,直到窗口关闭,随后执行 {dispose} 释放窗口。'
tutorial.window.notes: '构建并运行程序,检查窗口能否打开、移动、调整大小和关闭。此时还没有提交渲染命令,窗口内容尚未定义。关闭窗口后再继续。'
tutorial.window.title: '创建窗口'
ui.action.copy: '复制'
@@ -525,7 +493,7 @@ ui.api.noNamespaceTypes: '此命名空间中没有类型。'
ui.api.noTypes: '没有匹配的类型。'
ui.api.types: '类型'
ui.content.reference: '参考'
-ui.content.source: '源代码'
+ui.content.examples: '代码示例'
ui.content.tutorial: '教程'
ui.contents.close: '关闭目录'
ui.contents.open: '打开目录'
@@ -562,7 +530,6 @@ ui.reference.exceptions: '异常'
ui.reference.extensionMethods: '扩展方法'
ui.reference.fields: '字段'
ui.reference.implementations: '显式接口实现'
-ui.reference.implements: '实现'
ui.reference.inheritance: '继承'
ui.reference.inheritedMembers: '继承的成员'
ui.reference.interfaces: '接口'
diff --git a/documents/locales/zh-CN/translation.md b/documents/locales/zh-CN/translation.md
index 29908c60..a3761d3d 100644
--- a/documents/locales/zh-CN/translation.md
+++ b/documents/locales/zh-CN/translation.md
@@ -65,36 +65,37 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
## 术语
-| 英文 | 约定译法或处理 |
-| ---------------------------------- | ------------------------------------------------------------- |
-| rendering hardware interface / RHI | 渲染硬件接口(RHI);之后可直接使用 RHI |
-| graphics context | 图形上下文 |
-| command queue | 命令队列 |
-| command buffer | 命令缓冲区 |
-| command recording | 命令录制 |
-| submit / submission | 提交/提交操作;与 GPU 执行区分 |
-| resource | 资源 |
-| resource usage | 资源用途 |
-| resource ownership / lifetime | 资源所有权/生命周期 |
-| buffer | 缓冲区;标识符 `Buffer` 保持原样 |
-| texture | 纹理 |
-| heap | 堆 |
-| view | 视图;区分资源视图与 UI 控件 |
-| render pass | 渲染通道 |
-| render target | 渲染目标 |
-| color attachment | 颜色附件 |
-| depth/stencil | 深度/模板 |
-| pipeline | 管线;按上下文使用图形管线或计算管线 |
-| shader / entry point | 着色器/入口点 |
-| vertex / fragment | 顶点/片元 |
-| rasterization | 光栅化 |
-| viewport / scissor | 视口/裁剪区域 |
-| swap chain / presentation | 交换链/呈现 |
-| surface(呈现语境) | 原生呈现目标;`Surface` 标识符不译 |
-| drawable | 当前帧的输出纹理;`Drawable` 标识符不译,不一律称为交换链图像 |
-| framebuffer | 帧缓冲区;尺寸以原文规定的像素单位表述 |
-| barrier / timeline | 屏障/时间线 |
-| bindless | 无绑定;保留 API 标识符 |
-| upload | 上传 |
-| download / readback | GPU 数据语境使用“回读”;下载文件时使用“下载” |
-| undefined | 未定义;不能改写为某个具体默认结果 |
+| 英文 | 约定译法或处理 |
+| ---------------------------------- | ------------------------------------------------------------------------------------------- |
+| rendering hardware interface / RHI | 渲染硬件接口(RHI);之后可直接使用 RHI |
+| graphics API / implementation | 图形 API/图形 API 实现;本项目对应 DirectX 12、Metal 4 和 Vulkan 1.4,相关包是各自的实现包 |
+| graphics context | 图形上下文 |
+| command queue | 命令队列 |
+| command buffer | 命令缓冲区 |
+| command recording | 命令录制 |
+| submit / submission | 提交/提交操作;与 GPU 执行区分 |
+| resource | 资源 |
+| resource usage | 资源用途 |
+| resource ownership / lifetime | 资源所有权/生命周期 |
+| buffer | 缓冲区;标识符 `Buffer` 保持原样 |
+| texture | 纹理 |
+| heap | 堆 |
+| view | 视图;区分资源视图与 UI 控件 |
+| render pass | 渲染通道 |
+| render target | 渲染目标 |
+| color attachment | 颜色附件 |
+| depth/stencil | 深度/模板 |
+| pipeline | 管线;按上下文使用图形管线或计算管线 |
+| shader / entry point | 着色器/入口点 |
+| vertex / fragment | 顶点/片元 |
+| rasterization | 光栅化 |
+| viewport / scissor | 视口/裁剪区域 |
+| swap chain / presentation | 交换链/呈现 |
+| surface(呈现语境) | 原生呈现目标;`Surface` 标识符不译 |
+| drawable | 当前帧的输出纹理;`Drawable` 标识符不译,不一律称为交换链图像 |
+| framebuffer | 帧缓冲区;尺寸以原文规定的像素单位表述 |
+| barrier / timeline | 屏障/时间线 |
+| bindless | 无绑定;保留 API 标识符 |
+| upload | 上传 |
+| download / readback | GPU 数据语境使用“回读”;下载文件时使用“下载” |
+| undefined | 未定义;不能改写为某个具体默认结果 |
diff --git a/documents/locales/zh-TW/strings.yml b/documents/locales/zh-TW/strings.yml
index 68619138..220cc3af 100644
--- a/documents/locales/zh-TW/strings.yml
+++ b/documents/locales/zh-TW/strings.yml
@@ -1,5 +1,5 @@
### YamlMime:Resources
-concepts.execution.context.description: '{graphicsContext} 透過特定後端連接應用程式與 GPU 裝置,並提供圖形、計算與傳輸佇列。一起使用的資源必須屬於同一上下文;緩衝區、紋理、著色器、管線及其控制代碼不能跨上下文繫結。'
+concepts.execution.context.description: '{graphicsContext} 透過所選圖形 API 連接應用程式與 GPU 裝置,並提供圖形、計算與傳輸佇列。一起使用的資源必須屬於同一上下文;緩衝區、紋理、著色器、管線及其控制代碼不能跨上下文繫結。'
concepts.execution.context.details: '{capabilities} 提供裝置名稱與支援的功能。建立光線追蹤或網格著色所需的資源前,分別透過 {rayTracingSupported} 與 {meshShadingSupported} 確認支援情況。{link}與{detail}範例展示了初始化時的檢查方式。'
concepts.execution.context.details.detail: '網格著色'
concepts.execution.context.details.link: '光線追蹤'
@@ -26,14 +26,14 @@ concepts.execution.pipelines.guidance.detail: '計算範例'
concepts.execution.pipelines.guidance.link: '三角形的渲染回呼'
concepts.execution.pipelines.title: '管線狀態'
concepts.execution.queues.description: '一個影格同時包含繪製、計算與複製時,通常從 {graphicsQueue} 開始。將彼此相依的操作放在同一佇列,能簡化順序管理。'
-concepts.execution.queues.details: '不同佇列可分別接收獨立的工作負載,但未必對應獨立的硬體引擎。若工作能從重疊執行中受益,再考慮增加佇列。當一個佇列使用另一個佇列產生的資料時,需要在兩次提交之間建立明確的相依關係。'
+concepts.execution.queues.details: '增加佇列有助於讓獨立的工作負載重疊執行,但佇列未必對應獨立的硬體引擎。一個佇列要使用另一個佇列寫入的資料時,應在兩次提交之間建立明確的相依關係。'
concepts.execution.queues.guidance: '即使位於同一佇列,彼此相依的操作也可能需要屏障或紋理轉換,讓後續存取讀到先前寫入的結果。這種記憶體相依關係與提交順序不同,具體指定方式見{link}。'
concepts.execution.queues.guidance.link: '同步'
concepts.execution.queues.table.computeQueue.workToRecord: '計算分派與相容的傳輸工作,不包含圖形渲染通道。'
concepts.execution.queues.table.graphicsQueue.workToRecord: '渲染通道、繪製、計算與傳輸操作。'
concepts.execution.queues.table.headings.queue: '佇列'
concepts.execution.queues.table.headings.workToRecord: '支援的工作'
-concepts.execution.queues.table.transferQueue.workToRecord: '上傳、回讀與複製工作,不包含繪圖或計算分派。'
+concepts.execution.queues.table.transferQueue.workToRecord: '上傳、回讀與複製工作,不包含繪製或計算分派。'
concepts.execution.queues.title: '佇列選擇'
concepts.execution.recording.context: '佇列會回收已完成的命令緩衝區以供重複使用。每次記錄時,透過 {queueCommandBuffer} 取得緩衝區,同一時間只由一個執行緒記錄,而且只提交一次。提交後交由佇列管理,不再修改、重複提交或自行釋放。'
concepts.execution.recording.description: '{queueCommandBuffer} 傳回的 {commandBuffer} 已開始記錄。完成操作及其相依關係的記錄後,呼叫一次 {submit},結束記錄並提交命令。傳回的 {timelineValue} 識別這次提交在佇列上的完成點。'
@@ -42,17 +42,15 @@ concepts.execution.recording.guidance: '記錄會建立命令序列,{submit}
concepts.execution.recording.title: '記錄與提交'
concepts.execution.title: '執行模型'
concepts.platforms.description: '呈現流程可以由應用程式管理,也可以交給 UI 渲染控制項。這決定了誰來取得目前影格的輸出紋理、記錄與提交命令,以及顯示渲染結果。'
-concepts.platforms.frame.context: '在通道內繫結管線並記錄繪製命令,處理程式返回前須結束通道。控制項負責提交命令與呈現結果;處理程式不可自行提交命令緩衝區,也不可釋放傳入的命令緩衝區或輸出紋理。若改變了輸出紋理的佈局,返回前須恢復為 {colorAttachment},讓控制項能完成最後的轉換。'
+concepts.platforms.frame.context: '在通道內繫結管線並記錄繪製命令,處理程式返回前須結束通道。處理程式不可自行提交命令緩衝區,也不可釋放傳入的命令緩衝區或輸出紋理。若改變了輸出紋理的佈局,返回前須恢復為 {colorAttachment},讓控制項能完成最後的轉換。'
concepts.platforms.frame.description: '各控制項實作 {iZenithView} 介面。應用程式設定 {graphicsContext},在 {updateRequested} 中更新場景,並在 {renderRequested} 中透過傳入的 {renderEventArgs} 記錄命令。'
concepts.platforms.frame.details: '每個影格中,控制項會取得輸出紋理與命令緩衝區,將輸出紋理轉換為 {colorAttachment},再呼叫更新和渲染處理程式。之後,控制項提交已記錄的工作,並透過對應框架的呈現機制顯示影像。'
concepts.platforms.frame.guidance: '先在檔案中加入 {usingZenithNET}。假定名為 {view} 的 {iZenithView} 執行個體已初始化,且已設定圖形上下文,可註冊以下處理程式來清除其輸出紋理:'
concepts.platforms.frame.notes: '初始轉換使用 {undefined},允許丟棄先前影像的內容。因此,每個影格都應重新繪製或清除整張影像。需要累積或快取的渲染結果,可儲存在應用程式擁有的紋理中,再將該紋理繪製到控制項的輸出紋理上。'
-concepts.platforms.frame.reference: '{zenithViewHelperDrawableFormat} 提供這些整合使用的預設色彩格式。'
concepts.platforms.frame.title: '透過 UI 控制項渲染'
concepts.platforms.integration.context: 'WinForms、WPF 與 Windows 版 WinUI 整合在 Windows 上執行。使用 MAUI 時,安裝目標平台的工作負載,並透過 {useZenithView} 註冊控制項處理程式,具體見 {extensionsCs}。'
concepts.platforms.integration.description: '控制項共用事件介面,但呈現機制因框架而異:'
-concepts.platforms.integration.details: '各實作將 GPU 影像送到 UI 的方式不同。點陣圖回讀先將像素複製到 CPU 記憶體,再顯示影像;共用紋理互通能省去這次 CPU 複製,但仍可能需要 GPU 複製與同步。選擇整合方式時,除了共用的 {renderRequested} 事件介面,也應考慮其呈現方式。'
-concepts.platforms.integration.guidance: '透過 NuGet 加入所用 UI 框架的整合套件。Avalonia 對應的套件為 {avaloniaPackage}。'
+concepts.platforms.integration.details: 'UI 整合呈現 GPU 影像的方式各不相同。點陣圖回讀先將像素複製到 CPU 記憶體再顯示;共用紋理互通可省去這次複製,但仍可能需要 GPU 複製與同步。選擇整合方式時,應同時考量呈現路徑與共用的 {renderRequested} 事件。'
concepts.platforms.integration.table.avalonia.integration: 'Avalonia'
concepts.platforms.integration.table.avalonia.presentation: '渲染到紋理後,將像素回讀到 {writeableBitmap},實作見 {zenithViewCs} 和 {surfaceCs}。'
concepts.platforms.integration.table.headings.integration: '整合'
@@ -60,7 +58,7 @@ concepts.platforms.integration.table.headings.presentation: '呈現機制'
concepts.platforms.integration.table.maui.integration: '.NET MAUI'
concepts.platforms.integration.table.maui.presentation: 'Android、iOS 和 Mac Catalyst 使用原生呈現目標;Windows 使用共用紋理合成,具體見{link}。'
concepts.platforms.integration.table.maui.presentation.link: '平台實作'
-concepts.platforms.integration.table.uno.integration: 'Uno 路徑'
+concepts.platforms.integration.table.uno.integration: 'Uno Platform'
concepts.platforms.integration.table.uno.presentation: '將像素回讀到 {writeableBitmap},實作見 {zenithViewUnoCs}。'
concepts.platforms.integration.table.winForms.integration: 'WinForms'
concepts.platforms.integration.table.winForms.presentation: '為控制項的 {hWND} 建立 Zenith.NET 交換鏈,實作見 {zenithViewCs}。'
@@ -76,34 +74,34 @@ concepts.platforms.lifecycle.guidance: '應用程式的深度紋理或離屏紋
concepts.platforms.lifecycle.guidance.link: '旋轉立方體渲染器'
concepts.platforms.lifecycle.title: '交換鏈尺寸與生命週期'
concepts.platforms.ownership.description: '應用程式擁有所設定的上下文及其渲染資源,控制項擁有呈現資源。檢視的 {graphicsContext} 改變後,排程程式會為新上下文重建控制項資源。應用程式也須為該上下文重建自己的管線、緩衝區與紋理。'
-concepts.platforms.ownership.details: '替換渲染資源前,先停止檢視的影格活動,並等待使用這些資源的 GPU 工作完成,再釋放舊資源或上下文。移除檢視後,所設定的上下文仍由應用程式負責釋放。'
+concepts.platforms.ownership.details: '替換渲染資源前,先停止檢視的影格迴圈,並等待使用這些資源的 GPU 工作完成,再釋放舊資源。只有當所有檢視都已釋放該上下文對應的呈現資源,且應用程式透過它建立的資源也已全部釋放後,才能釋放上下文。'
concepts.platforms.ownership.guidance: '共用的 {frameSchedulerCs} 透過檢視的 UI 排程器執行影格處理程式。處理程式應專注於場景資料更新與命令記錄,其中耗時的 CPU 工作也會延遲介面回應。'
concepts.platforms.ownership.title: '應用程式與控制項的責任'
concepts.platforms.surface.description: '{link}使用 Silk.NET 建立視窗並處理事件。Zenith.NET 透過 {surface} 描述取得原生視窗控制代碼與尺寸,再據此建立 {swapChain}。作業系統視窗仍由應用程式負責管理。'
concepts.platforms.surface.description.link: '三角形教學'
-concepts.platforms.surface.details: '原生控制代碼必須與所選後端匹配:'
+concepts.platforms.surface.details: '原生控制代碼取決於圖形 API 與視窗系統。常見組合如下:'
concepts.platforms.surface.guidance: '{appCs} 中的範例宿主支援 Windows、macOS 與 X11。Linux 視窗提供 Xlib 控制代碼,因此在 Wayland 工作階段中需要 XWayland。原生 Wayland 應用程式則透過 {surfaceWayland} 提供顯示與表面的控制代碼。'
concepts.platforms.surface.table.android.backend: 'Android 上的 Vulkan。'
concepts.platforms.surface.table.apple.backend: 'Apple 平台上的 Metal。'
-concepts.platforms.surface.table.headings.backend: '後端與平台'
+concepts.platforms.surface.table.headings.backend: '圖形 API 與平台'
concepts.platforms.surface.table.headings.factory: '呈現目標工廠方法'
concepts.platforms.surface.table.headings.handles: '宿主程式提供的控制代碼'
-concepts.platforms.surface.table.wayland.backend: '具有原生 Wayland 宿主程式的 Vulkan。'
+concepts.platforms.surface.table.wayland.backend: 'Vulkan,使用原生 Wayland 視窗。'
concepts.platforms.surface.table.wayland.handles: 'Wayland 顯示與表面'
concepts.platforms.surface.table.win32.backend: 'Windows 上的 DirectX 12 或 Vulkan。'
-concepts.platforms.surface.table.xlib.backend: 'Linux 上帶有 X11 或 XWayland 的 Vulkan。'
+concepts.platforms.surface.table.xlib.backend: 'Linux 上的 Vulkan,使用 X11 或 XWayland。'
concepts.platforms.surface.table.xlib.handles: 'X11 顯示與視窗'
concepts.platforms.surface.title: '原生呈現目標'
concepts.platforms.title: '平台整合'
concepts.resources.allocation.context: '放置在堆積中的資源,在整個生命週期內都依賴堆積的儲存空間。最後一次 GPU 使用完成後,應先釋放資源,再釋放堆積。'
concepts.resources.allocation.description: '應用程式需要自行管理記憶體配置時,可以使用 {heap}。堆積為資源提供儲存空間,應用程式選擇明確的位元組位移來放置資源,並記錄各區域的使用情況。'
-concepts.resources.allocation.details: '對每個資源,使用建立時所需的緩衝區或紋理描述呼叫 {contextGetSizeAndAlignment}。依傳回的大小預留空間,起始位移須為傳回對齊值的整數倍,而且整個區域須位於堆積內,不與其他仍有效的配置重疊。紋理可能包含後端特有的填充,因此不能只依像素數量與每像素位元組數計算配置大小。'
+concepts.resources.allocation.details: '對每個資源,使用建立時所需的緩衝區或紋理描述呼叫 {contextGetSizeAndAlignment}。依傳回的大小預留空間,起始位移須為傳回對齊值的整數倍,而且整個區域須位於堆積內,不與其他仍有效的配置重疊。紋理配置可能包含填充,因此不能只依像素數量與每像素位元組數計算配置大小。'
concepts.resources.allocation.guidance: '放置在堆積中的緩衝區,必須使用與堆積相同的駐留設定。紋理儲存使用 GPU 專用堆積。'
concepts.resources.allocation.title: '堆積配置'
concepts.resources.bufferUsages.table.constant.role: '透過常數緩衝區繫結讀取的著色器參數。'
concepts.resources.bufferUsages.table.headings.role: '作用'
concepts.resources.bufferUsages.table.headings.usage: '用途'
-concepts.resources.bufferUsages.table.index.role: '索引繪圖所使用的索引。'
+concepts.resources.bufferUsages.table.index.role: '索引繪製所使用的索引。'
concepts.resources.bufferUsages.table.indirect.role: '間接繪製或分派命令讀取的引數。'
concepts.resources.bufferUsages.table.none.role: '未宣告任何緩衝區用途旗標。'
concepts.resources.bufferUsages.table.storageReadOnly.role: '透過唯讀著色器繫結存取的緩衝區資料。'
@@ -146,26 +144,26 @@ concepts.resources.transfers.description: '上傳將 CPU 資料複製到 GPU 資
concepts.resources.transfers.details: '呼叫這些方法前,先處理與其他佇列存取之間的衝突。方法內部的等待只涵蓋自身傳輸,不會建立與其他佇列的相依關係。直接透過映射記憶體複製時,則完全由呼叫端負責等待會產生衝突的 GPU 存取。'
concepts.resources.transfers.guidance: '若要將傳輸與其他 GPU 工作一起提交,可透過 {commandBufferUpload} 或 {commandBufferDownload} 記錄。上傳來源與回讀目標的記憶體生命週期要求不同:'
concepts.resources.transfers.item: '上傳呼叫期間,程式庫會將來源資料複製到內部的臨時上傳空間,也就是暫存記憶體。GPU 隨後從這塊空間讀取,因此應用程式的來源指標只需保持有效到呼叫返回。'
-concepts.resources.transfers.notes: '紋理傳輸中的列跨距是 CPU 資料相鄰兩列之間的位元組距離;切片跨距則是相鄰深度切片之間的位元組距離。傳輸操作依這些值,在 CPU 資料與紋理的 GPU 儲存空間之間複製內容。GPU 完成與資料送達回讀目標為何是兩個步驟,見{link}。'
-concepts.resources.transfers.notes.link: '同步'
+concepts.resources.transfers.layouts: '記錄紋理傳輸命令不會自動處理佈局轉換。上傳需要 {copyDst} 佈局,回讀需要 {copySrc} 佈局。應在複製之前記錄轉換至對應佈局的命令,並在複製之後轉換至下次使用所需的佈局。'
+concepts.resources.transfers.notes: '紋理傳輸中的列跨距是 CPU 資料相鄰兩列之間的位元組距離;切片跨距則是相鄰深度切片之間的位元組距離。傳輸操作依這些值,在 CPU 資料與紋理的 GPU 儲存空間之間複製內容。'
concepts.resources.transfers.table.bufferDownload.transfer: '對於 {cpuReadOnly},直接從映射記憶體複製;否則向傳輸佇列提交回讀,並等待完成。'
concepts.resources.transfers.table.bufferUpload.transfer: '對於 {cpuWriteOnly},直接複製到映射記憶體;否則向傳輸佇列提交上傳,並等待完成。'
concepts.resources.transfers.table.headings.method: '方法'
concepts.resources.transfers.table.headings.transfer: '傳輸行為'
concepts.resources.transfers.table.textureTransfers.method: '{textureUpload} / {textureDownload}'
concepts.resources.transfers.table.textureTransfers.transfer: '將複製及其紋理轉換提交到圖形佇列,並等待完成。操作結束後,所選子資源處於指定的最終佈局。'
-concepts.resources.transfers.title: '立即傳輸與命令記錄'
+concepts.resources.transfers.title: '即時傳輸與命令緩衝區傳輸'
concepts.resources.usages.description: '{bufferUsages} 與 {textureUsages} 是宣告資源用途的旗標列舉,分別設定於 {bufferDescUsages} 與 {textureDescUsages}。資源需要多種用途時,可透過 {value} 組合對應的成員。'
concepts.resources.usages.title: '資源用途'
-concepts.resources.views.description: '{bufferView} 描述緩衝區的一塊區域及其資料解讀方式。{textureView} 選擇子資源範圍,以及相容的紋理型別與格式。兩者都參考既有儲存空間,並遵循建立時宣告的用途。檢視範圍用來描述存取範圍,各後端並不因此提供一致的著色器邊界檢查。'
+concepts.resources.views.description: '{bufferView} 描述緩衝區的一塊區域及其資料解讀方式。{textureView} 選擇子資源範圍,以及相容的紋理型別與格式。兩者都參考既有儲存空間,並遵循建立時宣告的用途。檢視範圍描述存取區域,但無法保證不同實作中的著色器越界檢查一致。'
concepts.resources.views.details: '資源本身的控制代碼提供預設檢視。需要其他區域或相容的解讀方式時,再建立獨立檢視。檢視及其底層資源都必須保留到 GPU 使用結束;僅持有資源控制代碼,無法維持任一物件的存活。替換其中任一物件時,還須更新包含舊{link}的常數。'
concepts.resources.views.details.link: '資源控制代碼'
concepts.resources.views.title: '檢視與底層資源'
concepts.shaders.binding.context: '計算範例將 {inputTextureSampledHandle} 寫入 {input},將 {outputTextureStorageHandle} 寫入 {output}。在 Slang 中,{descriptorHandle} 的型別引數規定了著色器存取資源的方式:'
concepts.shaders.binding.description: '{setConstantBuffer} 選擇既有緩衝區與位元組位移,目前管線從該位置讀取常數。著色器使用這些參數前,先將資料上傳到對應的儲存空間。如果先前提交的 GPU 工作仍在讀取相同位元組,須等待該工作完成後再更新。'
concepts.shaders.binding.details: '準備好命令緩衝區、計算管線、已填入資料的常數緩衝區及執行緒群組數量後,依以下順序記錄分派。常數緩衝區會繫結到目前管線,因此必須先選擇管線:'
-concepts.shaders.binding.guidance: '這裡,{commandBuffer} 使用 {computePipeline} 及 {constantBuffer} 中的參數記錄分派。緩衝區需要宣告 {bufferUsagesConstant} 用途,位移 0 選擇其起始位置。若多筆常數記錄共用緩衝區,每筆記錄的起始位移還須符合後端繫結的對齊要求,這與記錄內部的欄位佈局是兩項不同要求。'
-concepts.shaders.binding.notes: '{resourceHandle} 包含兩個 32 位元欄位,含義由後端解釋,其值只在建立資源的上下文中有效。'
+concepts.shaders.binding.guidance: '常數緩衝區需要宣告 {bufferUsagesConstant} 用途。若多筆常數記錄共用緩衝區,每筆記錄的起始位移必須符合繫結對齊要求;這與記錄內部的欄位佈局是兩項不同要求。'
+concepts.shaders.binding.notes: '{resourceHandle} 包含兩個 32 位元欄位,具體意義取決於所選圖形 API 的實作;其值只在建立資源的上下文中有效。'
concepts.shaders.binding.reference: '保留資源及用於取得控制代碼的檢視,直到著色器完成最後一次存取。替換紋理或檢視後,應更新仍含舊控制代碼的常數。相關所有權規則見{link}。'
concepts.shaders.binding.reference.link: '資源管理'
concepts.shaders.binding.table.bufferStorageReadOnlyHandle.access: '讀取著色器型別 {t} 的結構化元素'
@@ -177,7 +175,7 @@ concepts.shaders.binding.table.samplerHandle.access: '紋理取樣狀態'
concepts.shaders.binding.table.textureSampledHandle.access: '紋理讀取'
concepts.shaders.binding.table.textureStorageHandle.access: '儲存紋理的讀寫'
concepts.shaders.binding.title: '常數緩衝區與資源控制代碼'
-concepts.shaders.compilation.description: '{zenithCompiler} 將指定的 Slang 進入點編譯為 {shaderDesc}。上下文的 {graphicsApi} 決定目標格式:DirectX 12 使用 DXIL,Metal 使用 Metal 程式庫,Vulkan 使用 SPIR-V。'
+concepts.shaders.compilation.description: '{zenithCompiler} 編譯 Slang 進入點並傳回 {shaderDesc}。上下文的 {graphicsApi} 決定輸出格式:DirectX 12 對應 {dxil},Metal 對應 {metallib},Vulkan 對應 {spirv}。'
concepts.shaders.compilation.details: '建立名為 {context} 的圖形上下文後,可以編譯已複製到執行檔所在目錄的三角形著色器:'
concepts.shaders.compilation.guidance: '進入點名稱 {vSMain} 必須與著色器檔案中的函式宣告一致。在初始化階段編譯著色器並建立管線,渲染期間重複使用管線。管線建立完成後,即可釋放著色器物件,具體見{link}。'
concepts.shaders.compilation.guidance.link: '第一個三角形'
@@ -193,7 +191,7 @@ concepts.shaders.layout.description: '對於頂點輸入,{inputLayout} 描述
concepts.shaders.layout.details: '常數緩衝區儲存著色器參數,結構化緩衝區儲存指定型別的元素陣列。它們的佈局由 Slang 宣告決定,不使用 {inputLayout}。C# 欄位位移、元素大小與填充,必須符合編譯後的著色器佈局。即使某個 C# 型別是非受控型別,可以直接依位元組複製,其記憶體排列也未必符合著色器要求;例如,頂點中緊密排列的 {float3},在著色器緩衝區中可能需要不同的對齊方式。'
concepts.shaders.layout.guidance: '著色器參數除了普通數值,也可以包含資源控制代碼。控制代碼識別的是既有儲存空間,因此將它複製到常數緩衝區,不會複製資源內容。'
concepts.shaders.layout.notes: '{computeShaderSlang} 中對應的宣告為:'
-concepts.shaders.layout.reference: '兩個尺寸值占用前 8 位元組,後面是兩個各占 8 位元組的控制代碼。C# 範例為整筆記錄預留 256 位元組。其他記錄的大小,應依各自欄位以及所需的佈局與對齊方式決定。'
+concepts.shaders.layout.reference: 'C# 欄位占用前 24 位元組:兩個尺寸值合計 8 位元組,每個控制代碼各占 8 位元組。整筆記錄預留 256 位元組,其餘位元組用於填充。其他參數區塊的欄位位移也必須符合著色器佈局。若多筆記錄共用緩衝區,還需在記錄之間保留足夠的填充,以符合繫結對齊要求。'
concepts.shaders.layout.title: '資料佈局'
concepts.shaders.matrices.description: '編譯器採用列優先的矩陣儲存方式,使同一列的元素連續排列。{link}在位移 0、64 和 128 處儲存三個 {matrix4x4} 值,其{detail}按模型、檢視和投影順序執行 {mulVectorMatrix}。'
concepts.shaders.matrices.description.detail: '著色器'
@@ -201,19 +199,19 @@ concepts.shaders.matrices.description.link: '旋轉立方體渲染器'
concepts.shaders.matrices.details: '儲存順序決定矩陣元素在記憶體中的排列,乘法順序決定變換。C# 與 Slang 應採用相互配合的約定。'
concepts.shaders.matrices.title: '矩陣約定'
concepts.shaders.title: '著色器資料與繫結'
-concepts.synchronization.backends.description: 'DirectX 12 與 Vulkan 將紋理轉換記錄為佈局與存取狀態的變更。在 Zenith.NET 的 Metal 後端中,{transition} 沒有對應的 GPU 操作。Metal 後端將命令組織成渲染與計算編碼器,並在編碼器結束時插入可見性屏障。同一編碼器內彼此相依的操作,例如連續的計算分派,透過明確呼叫 {barrier} 協調。'
-concepts.synchronization.backends.details: '{link}開始圖形渲染通道時,會結束計算編碼器,讓後續圖形工作能讀取計算輸出。連續兩次計算分派仍位於同一編碼器內,即使中間記錄了紋理轉換,也需要屏障來處理相依關係。因此,跨後端使用的命令序列既要考慮紋理佈局,也要處理存取之間的相依關係。'
+concepts.synchronization.backends.description: 'DirectX 12 與 Vulkan 將紋理轉換記錄為佈局與存取狀態的變更。在 Zenith.NET 的 Metal 實作中,{transition} 沒有對應的 GPU 操作。此實作將命令組織成渲染編碼器與計算編碼器,並在編碼器結束時插入可見性屏障。同一編碼器內彼此相依的操作,例如連續的計算分派,則透過明確呼叫 {barrier} 協調。'
+concepts.synchronization.backends.details: '{link}開始圖形渲染通道時,會結束計算編碼器,讓後續圖形工作能讀取計算輸出。連續兩次計算分派仍位於同一編碼器內,即使中間記錄了紋理轉換,也需要屏障來處理相依關係。'
concepts.synchronization.backends.details.link: '計算範例'
-concepts.synchronization.backends.title: '後端行為'
+concepts.synchronization.backends.title: '不同圖形 API 下的同步行為'
concepts.synchronization.barriers.context: '選擇涵蓋相關存取,且目前佇列支援的階段。{barrierStagesAll} 包含所有支援的階段;若相依關係只涉及其中一部分,可選擇較小的範圍。'
concepts.synchronization.barriers.description: '假設同一個命令緩衝區內有兩次計算分派,第一次寫入模擬資料,第二次讀取這些資料。在兩次分派之間設定屏障,讓第二次分派讀到已完成的寫入結果。對於儲存緩衝區,這樣即可安排存取順序,不需要進行紋理佈局轉換:'
concepts.synchronization.barriers.details: '第一個引數指定產生資料的階段,第二個引數指定使用資料的階段。兩者共同描述兩次分派之間所需的執行順序與記憶體可見性。'
-concepts.synchronization.barriers.guidance: '{link}在模擬步驟之間採用這個方式。每道屏障都位於產生資料的分派之後、使用資料的分派之前。'
+concepts.synchronization.barriers.guidance: '{link}在模擬步驟之間採用這個方式。'
concepts.synchronization.barriers.guidance.link: 'FluidTank 模擬'
concepts.synchronization.barriers.title: '管線屏障'
concepts.synchronization.dependencies.description: '逐一確認每個資源有哪些存取涉及同一份資料。只要其中包含寫入,就必須維持所需的先後順序。兩次讀取本身沒有衝突,但仍需符合紋理佈局與呈現要求。CPU 更新資料或釋放資源前,也須等待 GPU 完成對該儲存空間的使用。'
concepts.synchronization.dependencies.details: '應根據操作執行的位置選擇機制:'
-concepts.synchronization.dependencies.guidance: '一項工作可能同時需要多種同步機制。例如,紋理由另一個佇列產生時,除了提交相依關係,還需為下一次使用設定正確的佈局。這兩項操作本身都不需要阻塞 CPU;只有 CPU 要存取或釋放相關資料時,才需要在 CPU 端等待。'
+concepts.synchronization.dependencies.guidance: '一個佇列寫入的紋理被另一佇列使用時,應在提交之間建立相依關係,並記錄所需的佈局轉換。這兩步不會阻塞 CPU。CPU 要存取資料或釋放資源前,才需等待相關工作完成。'
concepts.synchronization.dependencies.table.cpuAccess.mechanism: '針對相關完成值呼叫 {wait}。'
concepts.synchronization.dependencies.table.cpuAccess.situation: 'CPU 存取或資源釋放需要等待 GPU 完成'
concepts.synchronization.dependencies.table.crossQueue.mechanism: '將生產者的 {timelineValue} 傳給消費者的 {submit}。'
@@ -256,7 +254,7 @@ home.entries.reference.category: '參考'
home.entries.reference.description: '查閱 API 型別、成員與宣告'
home.entries.reference.title: 'API 參考'
home.entries.samples.action: '瀏覽範例'
-home.entries.samples.category: '範例'
+home.entries.samples.category: '程式碼範例'
home.entries.samples.description: '可直接執行的圖形與計算範例'
home.entries.samples.title: '範例'
home.entries.title: '文件'
@@ -265,9 +263,9 @@ home.entries.tutorial.category: '教學'
home.entries.tutorial.description: '從空白專案開始,繪製第一個三角形'
home.entries.tutorial.title: '第一個三角形'
home.introduction.accent: '跨平台圖形應用'
-home.introduction.description: 'Zenith.NET 提供統一的圖形與計算 API,支援 DirectX、Metal 與 Vulkan'
+home.introduction.description: 'Zenith.NET 提供統一的圖形與計算 API,支援 DirectX 12、Metal 4 與 Vulkan 1.4'
home.introduction.title: '以 .NET 開發{lineBreak}{accent}'
-home.meta.description: '透過 Zenith.NET 開發跨平台圖形與計算應用程式,以共用 API 使用 DirectX、Metal 與 Vulkan'
+home.meta.description: '透過 Zenith.NET 開發跨平台圖形與計算應用程式,以共用 API 使用 DirectX 12、Metal 4 與 Vulkan 1.4'
home.scene.description: '可互動的旋轉幾何體。拖動或使用方向鍵調整視角。'
home.scene.label: '幾何體顯示'
home.scene.surface: '表面'
@@ -290,71 +288,65 @@ learning.title: '學習'
reference.description: '資源、命令與平台整合的參考文件'
reference.entries.commands.description: '圖形、計算與傳輸命令'
reference.entries.commands.label: '記錄命令'
-reference.entries.context.description: '為所選後端建立 GPU 資源'
+reference.entries.context.description: '透過圖形上下文建立 GPU 資源'
reference.entries.context.label: '從這裡開始'
reference.meta.description: 'Zenith.NET 的命名空間、型別與成員'
reference.navigation.core: '核心 API 參考'
reference.title: 'API 參考'
-samples.computeShader.description: '範例載入 {assetsTexturesShokoPng},透過一次計算分派將影像轉成灰階,再顯示輸出紋理。轉換只執行一次,後續影格顯示同一結果。渲染器展示了取樣紋理與可寫紋理的繫結、向上取整群組數量以覆蓋整張影像的計算方式,以及著色器中的影像邊界檢查。'
+samples.computeShader.description: '計算著色器將彩色影像轉換為灰階影像,展示 GPU 影像處理。'
samples.computeShader.details: '{computeShaderRendererCs} · {computeShaderSlang}'
samples.computeShader.title: '計算著色器'
-samples.cube.description: '旋轉立方體加入索引繪製、常數緩衝區中的模型、檢視和投影矩陣,以及深度測試。視窗調整大小時,會重建 {d32FloatS8UInt} 深度/樣板紋理。'
+samples.cube.description: '透過旋轉立方體展示索引繪製、三維變換與深度測試。'
samples.cube.details: '{spinningCubeRendererCs} · {spinningCubeSlang}'
samples.cube.title: '旋轉立方體'
-samples.description: '每個範例均由 C# 渲染器與 Slang 著色器組成,集中說明一項技術。完整的應用程式設定與渲染順序見{link}。'
-samples.description.link: '第一個三角形'
+samples.description: '這些範例涵蓋渲染與計算,從單一三角形到互動式應用程式與診斷工具。'
samples.execution.description: '執行 {link} 專案,並從主控台選單選擇範例。'
samples.execution.description.link: 'ZenithTutorials'
samples.execution.title: '執行範例'
-samples.host.description: '{appCs} 初始化上下文、視窗和交換鏈。每個影格取得命令緩衝區,呼叫所選渲染器,提交命令並呈現結果。{iRendererCs} 規定渲染器的更新、渲染、調整大小和釋放操作。'
-samples.host.details: '計算與光線追蹤渲染器產生離屏紋理。{texturePresenterCs} 與 {presentTextureSlang} 將這些紋理繪製到目前的輸出紋理,接著由共用宿主提交命令並呈現這個影格。'
-samples.host.title: '宿主與呈現'
-samples.indirectDrawing.description: '間接繪製透過索引繪製引數緩衝區,以及儲存各執行個體資料的結構化緩衝區,繪製多個立方體。CPU 提供繪製引數並更新變換。'
+samples.indirectDrawing.description: '以網格狀排列、各自旋轉的彩色立方體,展示使用繪製引數緩衝區的間接繪製。'
samples.indirectDrawing.details: '{indirectDrawingRendererCs} · {indirectDrawingSlang}'
samples.indirectDrawing.title: '間接繪製'
-samples.meshShading.description: '任務著色器剔除球體執行個體,將保留的索引傳給負責產生幾何體的網格著色器。建立管線前,渲染器檢查 {contextCapabilitiesMeshShadingSupported}。'
+samples.meshShading.description: '本範例使用任務著色器與網格著色器繪製彩色球體陣列,並略過相機視野外的球體。需要網格著色支援。'
samples.meshShading.details: '{meshShadingRendererCs} · {meshShadingSlang}'
samples.meshShading.title: '網格著色'
-samples.rayTracing.description: '此範例為地面與程序化球體建立底層及頂層加速結構,再於計算著色器內執行內嵌光線查詢。初始化前檢查 {contextCapabilitiesRayTracingSupported}。'
+samples.rayTracing.description: '本範例透過光線查詢繪製具有反射效果的球體,以及它們在棋盤格地面上的陰影。需要光線追蹤支援。'
samples.rayTracing.details: '{rayTracingRendererCs} · {rayTracingSlang}'
samples.rayTracing.title: '光線追蹤'
samples.title: '範例'
-samples.triangle.description: '三角形範例將頂點緩衝區與對應的輸入佈局關聯,再透過圖形管線繪製三個頂點。'
+samples.triangle.description: '用一個三角形展示基礎圖形管線,色彩在三個頂點之間平滑過渡。'
samples.triangle.details: '{helloTriangleRendererCs} · {helloTriangleSlang} · {link}'
samples.triangle.details.link: '完整教學'
samples.triangle.title: 'Hello Triangle'
-samples.workloads.description: '主存放庫的{link}包含規模較大的應用程式,這些專案直接參考程式庫原始碼。'
+samples.workloads.description: 'Zenith.NET 儲存庫的 {link} 收錄以下應用程式與工具。'
samples.workloads.description.link: 'Experiments 目錄'
-samples.workloads.details: '視窗實驗專案採用相同的 Windows、macOS 和 Linux/X11 呈現路徑。Avalonia、WinForms、WPF、WinUI/Uno 和 MAUI 控制項的影格生命週期及實作程式碼見{link}。'
-samples.workloads.details.link: '平台整合'
samples.workloads.table.cornellBox.example: '{link}'
samples.workloads.table.cornellBox.example.link: 'CornellBox'
-samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '路徑追蹤、降噪、色調對應、影像升頻與 ImGui 控制項。需要光線追蹤支援。'
+samples.workloads.table.cornellBox.whatItDemonstratesAndRequires: '用於觀察光照與反射效果的互動式室內場景。需要光線追蹤支援。'
samples.workloads.table.fluidTank.example: '{link}'
samples.workloads.table.fluidTank.example.link: 'FluidTank'
-samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '計算流體模擬、模擬階段之間的相依關係,以及多通道表面渲染。'
+samples.workloads.table.fluidTank.whatItDemonstratesAndRequires: '模擬水在水箱中的運動,提供水體與粒子兩種顯示方式。'
samples.workloads.table.headings.example: '範例'
-samples.workloads.table.headings.whatItDemonstratesAndRequires: '技術與執行要求'
+samples.workloads.table.headings.whatItDemonstratesAndRequires: '簡介'
samples.workloads.table.inkCanvas.example: '{link}'
samples.workloads.table.inkCanvas.example.link: 'InkCanvas'
-samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '在原生視窗中進行 Skia 繪圖與輸入處理。需要目標平台的後端與 Skia 原生程式庫。'
+samples.workloads.table.inkCanvas.whatItDemonstratesAndRequires: '支援自由繪製和擦除筆畫的畫布。'
samples.workloads.table.platformDetection.example: '{link}'
samples.workloads.table.platformDetection.example.link: 'PlatformDetection'
-samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '嘗試為每個後端建立上下文,並回報裝置功能。建立失敗時顯示為不支援,原因可能是裝置、驅動程式或缺少執行時所需的元件。'
-samples.workloads.title: '綜合應用'
-tutorial.context.description: '{graphicsContext} 透過後端連接應用程式與 GPU,並提供建立渲染資源的方法。'
+samples.workloads.table.platformDetection.whatItDemonstratesAndRequires: '在主控台中顯示圖形 API 的可用情況及裝置支援的功能。'
+samples.workloads.title: '應用程式與工具'
+tutorial.context.description: '{graphicsContext} 讓應用程式透過所選圖形 API 使用 GPU,並提供建立渲染資源的方法。'
tutorial.context.details: '在{emphasis}插入上下文初始化程式碼:'
tutorial.context.details.emphasis: 'using 指示詞之後、{iWindowWindow} 之前'
-tutorial.context.guidance: '各分支為目前平台選擇後端並要求啟用驗證。{validationMessage} 訊息會輸出到主控台。'
+tutorial.context.guidance: '各分支為所用圖形 API 請求啟用驗證。處理程式會將透過 {validationMessage} 回報的診斷訊息輸出到主控台。'
tutorial.context.imports: '在 {programCs} 頂端加入以下 using 指示詞:'
tutorial.context.title: '圖形上下文'
tutorial.description: '本教學從空白的 .NET 主控台專案開始,逐步建立視窗,並在其中繪製一個彩色三角形。'
tutorial.details: '本教學分三個階段確認結果:空白視窗、單色背景,以及彩色三角形。每完成一個階段,先執行程式檢查畫面,再繼續下一步。'
tutorial.draw.context: '{draw} 的引數如下:'
tutorial.draw.description: '在 {windowRender} 回呼中,用以下命令替換 {addTheTriangleDrawCommandsHereLater},位置保持在 {beginRenderPass} 與 {endRenderPass} 之間:'
-tutorial.draw.details: '{setPipeline} 選擇著色器和渲染狀態。後端按管線的輸入佈局解釋頂點繫結,因此這一步必須先於頂點繫結。'
+tutorial.draw.details: '{setPipeline} 選擇著色器與渲染狀態。管線的輸入佈局決定如何讀取頂點資料,因此必須先設定管線,再繫結頂點緩衝區。'
tutorial.draw.guidance: '{setVertexBufferVertexBuffer} 從緩衝區的位元組位移 0 開始,將已上傳的頂點資料繫結到輸入槽 0,對應 {inputLayouts} 中唯一的項目。'
-tutorial.draw.notes: '這些呼叫記錄繪製命令。既有的 {submitWait} 提交命令並等待 GPU 完成,接著由 {present} 要求顯示完成的影像。保留通道開始時的清除操作,讓三角形以外的區域也有確定的背景色。'
+tutorial.draw.notes: '保留通道開始時的清除操作,讓三角形以外的區域也有確定的背景色。'
tutorial.draw.table.firstInstance.meaning: '執行個體編號從零開始。'
tutorial.draw.table.firstVertex.meaning: '從緩衝區中的第一個頂點開始。'
tutorial.draw.table.headings.argument: '引數'
@@ -370,25 +362,25 @@ tutorial.execution.title: '執行應用程式'
tutorial.frame.commands.context: '{endRenderPass} 之後的第二次轉換讓輸出紋理進入可呈現的佈局。{submit} 結束記錄並提交命令緩衝區,{wait} 阻塞至本次提交完成,隨後 {present} 請求顯示渲染結果。'
tutorial.frame.commands.description: '渲染通道將寫入同一組附件的繪製操作放在一起。本通道使用交換鏈的輸出紋理接收色彩結果。{colorAttachmentClear} 指定以 RGBA 色彩初始化附件,並在通道結束時保留內容。{beginRenderPass} 依這些設定記錄通道的開始命令。'
tutorial.frame.commands.details: '集合中有一個色彩附件。{null} 表示此通道不使用深度/樣板附件。'
-tutorial.frame.commands.guidance: '{beginRenderPass} 預設讓視口與裁剪區域覆蓋整個附件。視口將渲染座標映射為像素位置,裁剪區域則限制可以寫入的範圍。'
+tutorial.frame.commands.guidance: '{beginRenderPass} 預設讓視口與裁剪區域覆蓋整個附件。視口將渲染座標映射為像素位置,裁剪區域則限制繪製可寫入的像素範圍。'
tutorial.frame.commands.title: '清除、提交與呈現'
-tutorial.frame.description: '先將視窗填滿單一背景色,這個操作稱為清除。背景正常顯示後,就能確認呈現目標、命令提交與呈現流程已連接完成,接著再加入三角形的頂點與著色器。'
-tutorial.frame.details: 'Silk.NET 在需要繪製一個影格時呼叫渲染回呼。本範例不使用回呼傳入的時間間隔,因此將該引數命名為 {value}。在{emphasis}註冊回呼:'
+tutorial.frame.description: '先用一種背景色填滿視窗,這稱為清除。若色彩正常顯示,表示命令提交與畫面呈現已生效。接著再加入三角形的頂點與著色器。'
+tutorial.frame.details: 'Silk.NET 在需要繪製一個影格時呼叫渲染回呼。在{emphasis}註冊回呼:'
tutorial.frame.details.emphasis: '{windowRun} 之前'
-tutorial.frame.target.description: '{graphicsQueueCommandBuffer} 傳回可直接記錄的命令緩衝區。記錄描述 GPU 工作,提交後才開始執行。'
-tutorial.frame.target.details: '紋理佈局描述操作如何存取紋理。第一次 {transition} 讓輸出紋理準備好作為色彩附件。這裡的 {default} 選擇 mip 級別 0 與陣列層 0,也就是輸出紋理的基本影像。由於這個通道會清除整張影像,可以指定 {undefined},允許丟棄先前內容。'
+tutorial.frame.target.description: '命令佇列接收已記錄的工作,交由 GPU 執行。{graphicsQueueCommandBuffer} 從圖形佇列取得已開始記錄的命令緩衝區。記錄描述 GPU 要執行的工作,提交後才開始執行。'
+tutorial.frame.target.details: '紋理佈局描述操作如何存取紋理。第一次 {transition} 讓輸出紋理準備好作為色彩附件。這裡的 {default} 選擇 mip 級別 0 與陣列層 0,也就是輸出紋理的基本子資源。由於這個通道會清除整張影像,可以指定 {undefined},允許丟棄先前內容。'
tutorial.frame.target.guidance: '呈現後可能換用另一張影像,因此每個影格都要重新取得目前的輸出紋理。'
tutorial.frame.target.title: '準備輸出紋理'
tutorial.frame.title: '第一個影格'
tutorial.geometry.data.description: '在{emphasis}新增頂點陣列。後續資源初始化也放在該回呼之前,順序如下。'
tutorial.geometry.data.description.emphasis: '{windowRender} 之前'
-tutorial.geometry.data.details: '每個條目構造一個 {vertex},內部的兩個 {new} 表示式分別提供 {vector3} 位置和 {vector4} 顏色。三個位置對應上角、右下角和左下角。頂點著色器將 {w} 作為第四個位置座標;w 為 1 時,x、y 也就是正規化裝置座標,-1 與 +1 對應影像邊界,0 對應中心,與像素尺寸無關。'
+tutorial.geometry.data.details: '三個位置分別構成三角形的上角、右下角和左下角。本例中,x、y 在影像內的範圍都是 -1 到 +1:0 對應中心,x 的正方向向右,y 的正方向向上。'
tutorial.geometry.data.guidance: '每個色彩包含紅、綠、藍與 alpha 分量,alpha 設為 1。三個頂點的 z 座標均為 0,位於同一平面。'
-tutorial.geometry.data.title: '頂點位置與顏色'
+tutorial.geometry.data.title: '頂點位置與色彩'
tutorial.geometry.description: '三角形的每個頂點都有位置與色彩。GPU 依三個位置決定三角形的形狀,再對頂點色彩內插,算出內部各處的色彩。'
tutorial.geometry.format.description: '在{emphasis}追加頂點宣告:'
tutorial.geometry.format.description.emphasis: '{programCs} 的結尾處、清理陳述式之後'
-tutorial.geometry.format.details: '{file} 將型別的使用範圍限定在 {programCs},{layoutKindSequential} 則保留欄位的宣告順序。{position} 包含三個 32 位元浮點數,位元組位移為 0;{color} 包含四個,位元組位移為 12。因此,每個頂點占 28 位元組。稍後會透過輸入佈局描述這個排列,讓 GPU 正確讀取各欄位。'
+tutorial.geometry.format.details: '{layoutKindSequential} 保留欄位的宣告順序。{position} 包含三個 32 位元浮點數,位元組位移為 0;{color} 包含四個,位元組位移為 12。因此,每個頂點占 28 位元組。輸入佈局會描述這個排列,讓 GPU 正確讀取各欄位。'
tutorial.geometry.format.imports: '在 {programCs} 頂端加入以下 using 指示詞,以使用向量型別與結構佈局屬性:'
tutorial.geometry.format.title: '頂點表示'
tutorial.geometry.title: '頂點資料'
@@ -397,8 +389,7 @@ tutorial.geometry.upload.description: '將頂點存入 {buffer},供 GPU 在繪
tutorial.geometry.upload.details: '配置大小為 {sizeofVertexVerticesLength},即三個 28 位元組頂點,共 84 位元組。{bufferUsagesVertex} 宣告頂點輸入用途,{cpuWriteOnly} 允許 CPU 直接初始化。描述中的跨距記錄元素大小,隨後定義的輸入佈局指定 GPU 如何讀取各個頂點屬性。'
tutorial.geometry.upload.guidance: '配置空間不會初始化緩衝區內容。{upload} 使用資料描述中的來源指標與位元組數,將陣列複製到目標位元組位移 0。'
tutorial.geometry.upload.imports: '在 {programCs} 頂端的 using 指示詞中加入 {bufferAlias},以區分 Zenith.NET 的緩衝區型別與 {systemBuffer}。'
-tutorial.geometry.upload.notes: '在 {programCs} 結尾的清理程式碼中,緊接在 {swapChainDispose} 之前加入 {vertexBufferDispose}。較大型靜態幾何體所需的 GPU 專用儲存與上傳方式,見{link}。'
-tutorial.geometry.upload.notes.link: '資源管理'
+tutorial.geometry.upload.notes: '在 {programCs} 結尾的清理程式碼中,緊接在 {swapChainDispose} 之前加入 {vertexBufferDispose}。'
tutorial.geometry.upload.title: '緩衝區配置與上傳'
tutorial.input.description: 'GPU 需要知道位置、色彩等頂點屬性儲存在哪裡。輸入佈局指定各屬性的格式與位元組位移,並以跨距表示兩個相鄰頂點相隔多少位元組。在建立著色器之後加入以下程式碼:'
tutorial.input.details: '{inputLayoutAdd} 將屬性依序排列,並將每個屬性的大小加到跨距中。位移是根據這裡提供的格式計算,不是透過檢查 C# 結構取得。這兩個欄位的佈局如下:'
@@ -413,43 +404,38 @@ tutorial.input.table.nextVertex.shaderInput: '下一筆輸入記錄'
tutorial.input.table.vertexColor.format: '{float4}(16 位元組)'
tutorial.input.table.vertexPosition.format: '{float3}(12 位元組)'
tutorial.input.title: '頂點輸入佈局'
-tutorial.lifecycle.description: '每個影格依次執行以下操作:'
-tutorial.lifecycle.details: '關閉視窗後,{run} 返回,程式繼續執行清理程式碼。每個影格都已等待其提交完成,因此現在可以釋放這些命令使用的資源。{windowRun} 之後完整的清理程式碼如下:'
+tutorial.lifecycle.description: '每個影格取得目前的輸出紋理,將其轉換至渲染所需的佈局,清除背景並繪製三角形;再轉換至呈現佈局,提交命令、等待完成並呈現。'
+tutorial.lifecycle.details: '關閉視窗後,{run} 返回,程式繼續執行清理程式碼。渲染回呼已等待每個影格提交的工作完成,因此現在可以釋放這些命令使用的資源。{windowRun} 之後完整的清理程式碼如下:'
tutorial.lifecycle.guidance: '先釋放交換鏈,再銷毀其原生視窗;先釋放應用程式資源,再釋放上下文。已提交的命令緩衝區由佇列回收,輸出紋理由交換鏈管理,兩者都不需要單獨呼叫 {dispose}。'
-tutorial.lifecycle.title: '影格生命週期與清理'
tutorial.pipeline.behavior: '在輸入佈局之後建立管線:'
tutorial.pipeline.context: '{cullNone} 關閉面剔除,因此無論頂點在畫面中呈順時針或逆時針排列,三角形都會被繪製。'
tutorial.pipeline.description: '{graphicsPipeline} 將頂點佈局、兩個著色器,以及圖元組裝和附件輸出所需的設定組合在一起。'
-tutorial.pipeline.details: '著色器負責處理頂點與片元。其餘管線設定決定圖元如何組裝、是否剔除特定朝向的面,以及如何執行深度測試和色彩混合:'
-tutorial.pipeline.guidance: '管線顏色格式必須匹配渲染通道附件,因此直接取自 {swapChainDescFormat}。{count1} 表示每像素一個取樣點。'
+tutorial.pipeline.guidance: '管線色彩格式必須匹配渲染通道附件,因此直接取自 {swapChainDescFormat}。{count1} 表示每像素一個取樣點。'
tutorial.pipeline.item: '{triangleList} 將每組連續的三個頂點組裝成一個三角形。'
tutorial.pipeline.notes: '{depthNone} 關閉深度測試和深度寫入,與通道沒有深度附件的設定一致。'
tutorial.pipeline.reference: '{opaque} 關閉混合,因此片元著色器輸出直接替換三角形內部的背景色。'
tutorial.pipeline.title: '圖形管線'
tutorial.pipeline.usage: '管線建立完成後即可釋放著色器物件。渲染期間保留管線,在清理程式碼中將 {pipelineDispose} 放在 {vertexBufferDispose} 之前。'
tutorial.presentation.title: '圖形上下文與呈現'
-tutorial.project.context: '在專案建置設定中啟用{emphasis}({allowUnsafeBlocks})。視窗輔助程式碼的原生呼叫和頂點上傳需要不安全程式碼。'
+tutorial.project.context: '在專案建置設定中啟用{emphasis}({allowUnsafeBlocks})。視窗輔助類別中的原生呼叫和頂點上傳需要不安全程式碼。'
tutorial.project.context.emphasis: '允許不安全的程式碼'
tutorial.project.description: '建立名為 {firstTriangle} 的 C# 主控台專案,目標框架設為 .NET 10。'
tutorial.project.details: '為專案加入以下 NuGet 套件:'
-tutorial.project.guidance: '{zenithNET} 提供統一渲染 API,三個後端套件提供各平台的實作。{zenithNETCompiler} 為所選後端編譯稍後介紹的 Slang 著色器。Silk.NET 負責視窗建立與事件處理。'
+tutorial.project.guidance: '{zenithNET} 提供共用的圖形與計算 API,三個圖形 API 套件分別實作它。{zenithNETCompiler} 為所選 API 編譯 Slang 著色器。'
tutorial.project.title: '專案設定'
-tutorial.requirements.context: '{link}及其{detail}提供了本教學的參考實作。'
-tutorial.requirements.context.detail: '共用宿主程式'
-tutorial.requirements.context.link: 'Hello Triangle 範例'
-tutorial.requirements.description: '需要 {emphasis},並具備基礎 C# 知識。應用程式以 {net10} 為目標框架。GPU 與驅動程式須支援所在平台選用的後端:'
+tutorial.requirements.description: '需要 {emphasis} 與基本 C# 知識。所用 GPU 與驅動程式還須具備下表中的圖形能力:'
tutorial.requirements.description.emphasis: '.NET 10 SDK'
-tutorial.requirements.guidance: 'Zenith.NET 渲染到應用程式提供的原生呈現目標。Silk.NET.Windowing 建立視窗並處理事件。macOS 使用由 {cAMetalLayerCs} 表示的 Metal 圖層,視窗輔助程式碼負責將它連接到視窗。'
-tutorial.requirements.table.headings.graphicsBackend: '圖形後端'
+tutorial.requirements.guidance: 'Zenith.NET 渲染到應用程式提供的原生呈現目標。Silk.NET.Windowing 建立視窗並處理事件。'
+tutorial.requirements.table.headings.graphicsBackend: '圖形能力'
tutorial.requirements.table.headings.platform: '平台'
-tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4'
+tutorial.requirements.table.linux.graphicsBackend: 'Vulkan 1.4 與 VK_EXT_descriptor_heap'
tutorial.requirements.table.linux.platform: 'Linux(X11 或 XWayland)'
tutorial.requirements.table.macOS.graphicsBackend: 'Metal 4'
tutorial.requirements.table.macOS.platform: 'macOS'
-tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12'
+tutorial.requirements.table.windows.graphicsBackend: 'DirectX 12 與 Shader Model 6.6'
tutorial.requirements.table.windows.platform: 'Windows'
tutorial.requirements.title: '準備事項'
-tutorial.resize.context: '再次建置並執行程式。調整視窗大小後,背景應繼續填滿整個視窗:每次開始新的渲染通道時,視口與裁剪區域都會依附件的新尺寸設定。保留渲染回呼,稍後將在這個通道內繪製三角形。'
+tutorial.resize.context: '再次建置並執行程式。調整視窗大小後,背景應繼續填滿整個視窗。保留渲染回呼,稍後將在這個通道內繪製三角形。'
tutorial.resize.description: '畫面緩衝區尺寸改變時,交換鏈也要跟著調整。在渲染回呼之後、{windowRun} 之前註冊 {framebufferResize} 回呼:'
tutorial.resize.details: '這裡接收的是以像素為單位的{link},而不是視窗邏輯尺寸的變化。視窗最小化時,畫面緩衝區的寬度或高度可能變成零。此時,尺寸變更回呼保留現有交換鏈,不進行調整。渲染回呼也會在任一尺寸為零時直接返回,直到畫面緩衝區恢復有效尺寸後才繼續繪製。'
tutorial.resize.details.link: '畫面緩衝區大小變更'
@@ -461,51 +447,33 @@ tutorial.shaders.compilation.description: '將 {triangleSlang} 的檔案屬性{e
tutorial.shaders.compilation.description.detail: '有更新時才複製'
tutorial.shaders.compilation.description.emphasis: '複製到輸出目錄'
tutorial.shaders.compilation.details: '回到 {programCs},在頂點上傳之後、渲染回呼之前加入著色器初始化:'
-tutorial.shaders.compilation.guidance: '{zenithCompiler} 為 {contextGraphicsApi} 指定的後端編譯原始碼,{createShader} 再依編譯後的描述建立著色器物件。進入點名稱 {vSMain} 與 {fSMain} 分別選取 Slang 檔案中定義的兩個函式。'
+tutorial.shaders.compilation.guidance: '{zenithCompiler} 依 {contextGraphicsApi} 指定的圖形 API 編譯原始碼,{createShader} 再依編譯後的描述建立著色器物件。進入點名稱 {vSMain} 與 {fSMain} 分別選取 Slang 檔案中定義的兩個函式。'
tutorial.shaders.compilation.title: '編譯著色器'
tutorial.shaders.context: '{fSInput} 連接兩個著色器階段。頂點著色器將裁剪空間位置寫入 {sVPOSITION},GPU 據此判斷三角形的可見部分。{cOLOR0} 欄位傳遞頂點色彩,經過三角形內部的內插後再交給片元著色器。兩個階段必須採用相同的色彩型別與語義。'
tutorial.shaders.description: '著色器是在 GPU 上執行的程式。頂點著色器決定每個頂點的位置,片元著色器則決定影像中被覆蓋位置的色彩。接下來會將兩個階段寫在同一個 Slang 檔案,並分別定義進入點,也就是各階段開始執行的函式。'
-tutorial.shaders.details: '建立 {triangleSlang},先定義輸入與輸出結構:'
+tutorial.shaders.details: '在專案根目錄建立 {triangleSlang},定義以下輸入與輸出結構:'
tutorial.shaders.fragment.description: '在同一檔案中追加片元進入點:'
tutorial.shaders.fragment.details: '光柵化判定三角形在影像中的覆蓋範圍,並在這些位置產生片元。每個片元的色彩由三個頂點的色彩內插而得。{fSMain} 傳回這個色彩,{sVTARGET} 則將結果送到第一個色彩附件。'
tutorial.shaders.fragment.title: '片元著色'
tutorial.shaders.guidance: '{vSInput} 定義頂點著色器輸入。{pOSITION0} 和 {cOLOR0} 按語義識別屬性,C# 欄位名稱本身不建立這一映射。'
tutorial.shaders.title: '著色器階段'
tutorial.shaders.vertex.description: '在 {triangleSlang} 中追加頂點進入點:'
-tutorial.shaders.vertex.details: 'GPU 為每個輸入頂點呼叫這一進入點,補充齊次座標 {w} 並傳遞顏色。頂點處理結束後,位置要除以 w。本例 w 為 1,x、y、z 保持不變,可直接解釋為正規化裝置座標。'
+tutorial.shaders.vertex.details: 'GPU 為每個輸入頂點執行這個函式。函式補上第四個位置分量 {w},並傳遞色彩。頂點處理結束後,GPU 將 x、y、z 分別除以 w,得到正規化裝置座標。本例 w 為 1,因此這些值維持不變。'
tutorial.shaders.vertex.title: '頂點著色'
tutorial.surface.description: '在{emphasis}指定原生呈現目標:'
tutorial.surface.description.emphasis: '{windowCenter} 之後、{windowRun} 之前'
tutorial.surface.details: '畫面緩衝區是視窗用來顯示的像素影像。{surface} 描述原生呈現目標及其尺寸,{framebufferSize} 則提供像素大小。啟用顯示縮放時,這個大小可能與視窗的邏輯尺寸不同。'
-tutorial.surface.guidance: '呈現目標提供後端所需的原生控制代碼:Windows 使用 Win32 視窗,Linux 使用 X11 顯示與視窗,macOS 使用已連接的 Metal 圖層。'
+tutorial.surface.guidance: '呈現目標提供所選圖形 API 所需的原生控制代碼:Windows 使用 Win32 視窗,Linux 使用 X11 顯示與視窗,macOS 使用已連接的 Metal 圖層。'
tutorial.surface.title: '原生呈現目標'
tutorial.swapChain.context: '交換鏈需要上下文與視窗才能運作。將 {programCs} 結尾的 {windowDispose} 換成以下釋放順序:'
tutorial.swapChain.description: '緊接呈現目標描述,建立交換鏈:'
tutorial.swapChain.details: '{swapChain} 管理視窗呈現的影像。{drawable} 以影像資源 {texture} 的形式提供目前影像。渲染後,{present} 請求顯示該影像,並推進到下一個輸出紋理。'
-tutorial.swapChain.guidance: '{b8G8R8A8UNorm} 按藍、綠、紅和 alpha 順序儲存四個 8 位元通道。{uNorm} 將整數 0–255 對應到 0–1。著色器仍輸出邏輯 RGBA 值,格式只規定儲存表示;管線透過 {swapChainDescFormat} 匹配附件。'
+tutorial.swapChain.guidance: '{b8G8R8A8UNorm} 按藍、綠、紅和 alpha 順序儲存四個 8 位元通道。{uNorm} 將整數 0–255 對應到 0–1。著色器仍輸出邏輯 RGBA 值,格式只規定儲存表示。'
tutorial.swapChain.title: '交換鏈'
tutorial.title: '第一個三角形'
-tutorial.troubleshooting.description: '結合主控台診斷與三個檢查點定位失敗階段:'
-tutorial.troubleshooting.details: '{link}與{detail}可用於核對頂點資料、輸入佈局和繪製操作。該範例將視窗與提交邏輯放入共用宿主程式,本教學則保留在 {programCs} 中。{context}進一步介紹索引繪製、變換與深度測試。'
-tutorial.troubleshooting.details.context: '旋轉立方體'
-tutorial.troubleshooting.details.detail: 'Slang 著色器'
-tutorial.troubleshooting.details.link: '範例渲染器'
-tutorial.troubleshooting.table.backend.check: '檢查選取的後端是否受到裝置與已安裝的圖形驅動程式支援。'
-tutorial.troubleshooting.table.backend.symptom: '後端建立失敗'
-tutorial.troubleshooting.table.drawing.check: '檢查上傳大小、輸入佈局、管線選擇,以及繪製命令是否位於渲染通道內。'
-tutorial.troubleshooting.table.drawing.symptom: '背景出現但三角形未出現'
-tutorial.troubleshooting.table.headings.check: '檢查項目'
-tutorial.troubleshooting.table.headings.symptom: '徵狀'
-tutorial.troubleshooting.table.input.check: '檢查跨距是否為 28 位元組,位置與色彩是否分別從位移 0 和 12 位元組開始。'
-tutorial.troubleshooting.table.input.symptom: '頂點位置或色彩異常'
-tutorial.troubleshooting.table.shaders.check: '檢查複製的 {triangleSlang}、進入點拼寫,以及編譯器回報的診斷資訊。'
-tutorial.troubleshooting.table.shaders.symptom: '背景色正常顯示,但著色器載入失敗'
-tutorial.troubleshooting.table.window.check: '確認 .NET 專案可成功建置,且僅含視窗的步驟可在桌面工作階段中執行。在 Linux 上,檢查 X11 或 XWayland 是否可用。'
-tutorial.troubleshooting.table.window.symptom: '視窗未開啟'
-tutorial.troubleshooting.title: '問題排查'
tutorial.window.description: '將 {cocoaHelperCs} 下載至專案中。此輔助類別負責將 Metal 圖層連接到 macOS 視窗。'
-tutorial.window.details: '將自動產生的 {programCs} 內容換成以下程式碼。它使用最上層陳述式,依書寫順序執行,不需要明確撰寫 {main} 方法。後續各節會指出新程式碼應加入的位置:'
-tutorial.window.guidance: '{graphicsAPINone} 將圖形上下文的建立交給 Zenith.NET。{initialize} 建立原生視窗,讓程式取得視窗系統的控制代碼;{center} 把視窗放在螢幕中央。{run} 持續處理事件直到視窗關閉,之後再執行 {dispose} 釋放視窗。'
+tutorial.window.details: '將 {programCs} 的內容換成以下程式碼:'
+tutorial.window.guidance: '{graphicsAPINone} 告訴 Silk.NET 不要建立圖形上下文;應用程式稍後會建立 Zenith.NET 上下文。{initialize} 建立原生視窗,讓程式取得視窗系統的控制代碼;{center} 把視窗置於螢幕中央。{run} 持續處理事件直到視窗關閉,之後再執行 {dispose} 釋放視窗。'
tutorial.window.notes: '建置並執行程式,確認視窗可以開啟、移動、調整大小及關閉。此時尚未提交渲染命令,視窗內容還沒有定義。關閉視窗後再繼續。'
tutorial.window.title: '建立視窗'
ui.action.copy: '複製'
@@ -525,12 +493,12 @@ ui.api.noNamespaceTypes: '此命名空間中沒有型別。'
ui.api.noTypes: '沒有相符的型別。'
ui.api.types: '型別'
ui.content.reference: '參考'
-ui.content.source: '原始碼'
+ui.content.examples: '程式碼範例'
ui.content.tutorial: '教學'
ui.contents.close: '關閉目錄'
ui.contents.open: '開啟目錄'
ui.contents.title: '目錄'
-ui.footer.caption: '面向 .NET 的現代 RHI'
+ui.footer.caption: '適用於 .NET 的現代 RHI'
ui.footer.label: '頁尾'
ui.language.label: '語言'
ui.language.unavailable: '未翻譯'
@@ -562,7 +530,6 @@ ui.reference.exceptions: '例外狀況'
ui.reference.extensionMethods: '擴充方法'
ui.reference.fields: '欄位'
ui.reference.implementations: '明確介面實作'
-ui.reference.implements: '實作'
ui.reference.inheritance: '繼承'
ui.reference.inheritedMembers: '繼承的成員'
ui.reference.interfaces: '介面'
diff --git a/documents/locales/zh-TW/translation.md b/documents/locales/zh-TW/translation.md
index 3a968e68..11192cfa 100644
--- a/documents/locales/zh-TW/translation.md
+++ b/documents/locales/zh-TW/translation.md
@@ -37,7 +37,7 @@
翻譯時尤其注意以下區別:
- 命令記錄、提交、GPU 執行及完成並非同一步驟。
-- 資源用途、記憶體駐留/CPU 存取意圖、紋理配置與像素格式是不同概念。
+- 資源用途、記憶體駐留/CPU 存取意圖、紋理佈局與像素格式是不同概念。
- 所有權表示釋放資源的責任;持有控制代碼不等於維持資源存活,提交命令也不會移轉所有權。
- GPU 完成不一定代表暫存的回讀資料已複製至應用程式的 CPU 目標;保留原文關於等待所屬佇列的說明。
- `drawable` 指目前影格的輸出紋理,不一律等同於交換鏈影像;資源檢視與 UI 控制項也須依情境區分。
@@ -65,39 +65,40 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
## 術語
-| 英文 | 約定用語 |
-| ----------------------------- | --------------------------------------------------------- |
-| API / GPU / RHI | 保留縮寫,首次依原文說明 |
-| barrier | 屏障 |
-| bindless | 無繫結 |
-| buffer | 緩衝區;`Buffer` 不變 |
-| color attachment | 色彩附件 |
-| command buffer | 命令緩衝區 |
-| command queue | 命令佇列 |
-| command recording | 命令記錄 |
-| depth/stencil | 深度/樣板 |
-| drawable | 目前影格的輸出紋理;`Drawable` 不變,不一律稱為交換鏈影像 |
-| framebuffer | 畫面緩衝區,尺寸依原文的像素單位表述 |
-| graphics context | 圖形上下文 |
-| heap | 堆積 |
-| pipeline | 管線;依情境區分圖形或計算管線 |
-| rasterization | 光柵化 |
-| readback | 從 GPU 回讀資料;下載檔案另用「下載」 |
-| render pass | 渲染通道 |
-| render target | 渲染目標 |
-| resource | 資源 |
-| resource ownership / lifetime | 資源所有權/生命週期 |
-| resource usage | 資源用途 |
-| shader / entry point | 著色器/進入點 |
-| submit / submission | 提交/提交操作,與 GPU 執行區分 |
-| surface | 呈現情境使用「原生呈現目標」;`Surface` 不變 |
-| swap chain / presentation | 交換鏈/呈現 |
-| texture | 紋理 |
-| timeline | 時間線 |
-| undefined | 未定義,不能改寫為某個預設結果 |
-| upload | 上傳資料 |
-| vertex / fragment | 頂點/片元 |
-| view | 資源檢視;與 UI 檢視區分 |
-| viewport / scissor | 視口/裁剪區域 |
+| 英文 | 約定用語 |
+| ----------------------------- | ----------------------------------------------------------------------------------------------- |
+| API / GPU / RHI | 保留縮寫,首次依原文說明 |
+| graphics API / implementation | 圖形 API/圖形 API 實作;本專案對應 DirectX 12、Metal 4 與 Vulkan 1.4,相關套件是各自的實作套件 |
+| barrier | 屏障 |
+| bindless | 無繫結 |
+| buffer | 緩衝區;`Buffer` 不變 |
+| color attachment | 色彩附件 |
+| command buffer | 命令緩衝區 |
+| command queue | 命令佇列 |
+| command recording | 命令記錄 |
+| depth/stencil | 深度/樣板 |
+| drawable | 目前影格的輸出紋理;`Drawable` 不變,不一律稱為交換鏈影像 |
+| framebuffer | 畫面緩衝區,尺寸依原文的像素單位表述 |
+| graphics context | 圖形上下文 |
+| heap | 堆積 |
+| pipeline | 管線;依情境區分圖形或計算管線 |
+| rasterization | 光柵化 |
+| readback | 從 GPU 回讀資料;下載檔案另用「下載」 |
+| render pass | 渲染通道 |
+| render target | 渲染目標 |
+| resource | 資源 |
+| resource ownership / lifetime | 資源所有權/生命週期 |
+| resource usage | 資源用途 |
+| shader / entry point | 著色器/進入點 |
+| submit / submission | 提交/提交操作,與 GPU 執行區分 |
+| surface | 呈現情境使用「原生呈現目標」;`Surface` 不變 |
+| swap chain / presentation | 交換鏈/呈現 |
+| texture | 紋理 |
+| timeline | 時間線 |
+| undefined | 未定義,不能改寫為某個預設結果 |
+| upload | 上傳資料 |
+| vertex / fragment | 頂點/片元 |
+| view | 資源檢視;與 UI 檢視區分 |
+| viewport / scissor | 視口/裁剪區域 |
列與行的用法依臺灣慣例:row 譯為「列」,column 譯為「行」。row-major 為「列優先」,row stride 為「列跨距」。記憶體配置與資料佈局須依語境區分。
diff --git a/documents/maintenance.md b/documents/maintenance.md
index 428aeb4e..47ecd27e 100644
--- a/documents/maintenance.md
+++ b/documents/maintenance.md
@@ -50,6 +50,7 @@ Do not turn the samples index into a sequence of advanced tutorials. The triangl
- Use one H1 and a clear H2/H3 hierarchy. Give explicit anchors to sections linked from other pages when their headings may change. Use the existing shared Markdown/HTML components with resource-bound text; use tables for comparisons, notices for necessary constraints and diagrams only when they clarify a relationship.
- Keep diagrams small enough to read on a phone. Prefer a vertical sequence to a wide horizontal graph when scaling would make its labels too small.
- Keep the homepage, Learn overview and README consistent with the documentation's contents. Do not publish placeholder pages or temporary validation notes.
+- Call DirectX 12, Metal 4 and Vulkan 1.4 graphics APIs, and describe their packages as implementations of the shared API. Use full graphics API versions when stating support; generic API names are appropriate when discussing behavior independent of a version. State .NET versions where readers need a concrete SDK or target framework to build or run an example, rather than in general project descriptions. Refer to framework controls as UI integrations or rendering controls.
## Editorial style
@@ -71,7 +72,7 @@ First locate and inspect the existing tutorial/sample source. This checkout has
The first triangle is a general .NET console application using NuGet packages. Specify the project name, target framework, and required packages. Do not replace package installation with source project references or cloning the main repository to accommodate the validation machine. Keep any explicitly authorized test-only package selection in a temporary project outside the repository.
-Introduce the windowing library, backend selection and native-surface differences before graphics setup. Use one shared application flow for Windows, macOS and Linux, identify the windowing requirements, and keep platform interop in a small, verified support file where possible. Do not turn this into a platform-specific SDK setup tutorial.
+Introduce the windowing library, graphics API selection and native-surface differences before graphics setup. Use one shared application flow for Windows, macOS and Linux, identify the windowing requirements, and keep platform interop in a small, verified support file where possible. Do not turn this into a platform-specific SDK setup tutorial.
Teach the triangle in cumulative steps: an empty window, a presented clear color, vertex data and upload, shaders, input layout, pipeline state, drawing, presentation and cleanup. Explain what each step contributes, why its settings are chosen and how its data connects to the next stage. Mark the exact file and insertion or replacement point for every partial snippet. Provide observable checkpoints, and ensure the assembled result is complete. Link to concepts for deeper decisions; do not substitute a finished-project code dump or a validation report for the reader's learning sequence.
@@ -83,9 +84,9 @@ Introduce file settings when the file is created. For a shader, describe its Cop
Keep snippets consistent with the complete application. The assembled source must not depend on omitted setup or unexplained helper methods. Keep platform-specific alternatives only where they are necessary to run it.
-For each sample, provide a verified source link, its purpose and relevant requirements. Avoid copying its implementation into the page. Use the repository's normal branch links rather than transient local paths or release-specific URLs unless the example requires otherwise.
+For each sample, briefly describe the visible result and the main technique it demonstrates, then provide verified source links. Include a prerequisite when it determines whether the sample can run. Keep API call sequences, resource formats, helper implementation details, and unrelated navigation out of the catalog. Link to the repository's default branch rather than transient local paths or release-specific URLs unless the example requires otherwise.
-For screenshots maintained in the tutorial repository, use its main-branch raw image URLs in shared Markdown. Link each preview to the full-size image, include its intrinsic dimensions, and use native lazy loading. Bind alternative text with `alt="@resource.key"` and `data-resource-alt="resource.key"`; an existing sample title can identify its preview when the adjacent prose explains the result. The build renders English alternative text, and language switching updates it from the selected dictionary.
+For screenshots maintained in the tutorial repository, use raw image URLs from its default branch in shared Markdown. Link each preview to the full-size image, include its intrinsic dimensions, and use native lazy loading. Bind alternative text with `alt="@resource.key"` and `data-resource-alt="resource.key"`; an existing sample title can identify its preview when the adjacent prose explains the result. The build renders English alternative text, and language switching updates it from the selected dictionary.
Compile the complete tutorial using its documented setup and run it to verify the visible triangle on the selected platform. A DocFX build validates the documentation, not the C# or shader examples. Report any platform that could not be exercised; do not claim cross-platform execution from a single-platform check.
@@ -167,11 +168,11 @@ This is a WPF-style resource model. `index.md`, `learn/` and `api/index.md` cont
`locales/en-US/strings.yml` is the sole English source dictionary. Each other language folder retains its permanent `translation.md` and, when translated, a `strings.yml`. A translator adds or updates only `strings.yml`, keeping the `### YamlMime:Resources` header and the complete source key set. No localized pages, TOCs, images, templates, scripts or configuration are needed. All resource values are strings.
-Language folders, registrations and menus use code order: `de-DE`, `en-US`, `es-ES`, `fr-FR`, `ja-JP`, `ko-KR`, `pt-BR`, `ru-RU`, `zh-CN`, `zh-TW`. English is explicitly the source and fallback. Complete resource dictionaries become available automatically after the normal DocFX build. Missing keys, stale extra keys, non-string values and changed placeholder names fail that build.
+Language folders, registrations and menus use language-code order: `de-DE`, `en-US`, `es-ES`, `fr-FR`, `ja-JP`, `ko-KR`, `pt-BR`, `ru-RU`, `zh-CN`, `zh-TW`. English is the source and fallback. Complete resource dictionaries become available automatically after the normal DocFX build. Missing keys, stale extra keys, non-string values and changed placeholder names fail that build.
Pages share the same URL paths. `?lang=` selects a dictionary, retaining the page and fragment. Without an explicit language, the site uses a saved manual selection, browser preferences, then English. An explicit unsupported or unpublished language falls back to English, without substituting a different saved language. A missing, stale or malformed downloaded dictionary is rejected before any translated text is applied, keeping the complete English page usable. The English HTML is fully rendered during the build; other static dictionaries bind to that same markup in the browser. No translation API is used. Search uses translated resources with the shared generated API index.
-Site-owned images remain in `images/`; screenshots maintained in the tutorial repository are referenced by their main-branch URLs. All generated API YAML remains in `api/`. This is a complete refactor, with no legacy route or compatibility layer. Do not create `pages/`, `snippets/`, a parallel content graph or an additional build command for localization.
+Site-owned images remain in `images/`; screenshots maintained in the tutorial repository are referenced by URLs from its default branch. All generated API YAML remains in `api/`. Localization uses the shared routes without a separate compatibility layer. Do not create `pages/`, `snippets/`, a parallel content graph or an additional build command for localization.
## Resource keys and placeholders
@@ -191,7 +192,7 @@ And in the shared page:
```
-The binding escapes text values and inserts only the shared slot markup. Preserve every placeholder name, including case, when translating. Reordering is allowed; adding or removing names is not. Use descriptive slot names for new content. Nested emphasis or link labels can have their own resources when they contain translatable prose. Executable examples, shader code and diagnostic/illustrative code blocks stay in shared Markdown unchanged.
+The binding escapes text values and inserts only the shared slot markup. Preserve every placeholder name, including case, when translating. Reordering is allowed; adding or removing names is not. Use descriptive slot names for new content. Nested emphasis or link labels can have their own resources when they contain translatable prose. Executable examples, shader code and code-like diagnostics stay in shared Markdown unchanged; explanatory flow summaries belong in localized prose.
Page front matter uses `title: '@tutorial.title'` and an optional resource-bound `description`. Navigation names bind keys through `name: '@tutorial.title'` in the root TOC. Keep heading IDs in shared markup so rewording or translating a title cannot change links.
@@ -219,7 +220,7 @@ docfx serve documents/_site --hostname 127.0.0.1 --port 8080
Check the resulting type page and a tutorial page in the browser. Verify links after highlighting, keyboard focus, copied code, long generic signatures and narrow layouts. A documented member should keep its summary, parameter descriptions, return/value explanation, remarks, examples and exceptions. An undocumented member should remain compact.
-Before handing off a content change, ensure the DocFX build has no warnings or errors, local links and fragments resolve, and the filled pages work at desktop and phone widths. Check headings, code/table overflow, search results and keyboard navigation on the changed pages. Summarize the pages filled, the source used, compilation/rendering checks performed and any unfinished content.
+Before handing off a content change, review the rendered articles in reading order for necessity, teaching sequence, and continuity across paragraphs. Review translations in that same context. Separately, ensure the DocFX build has no warnings or errors, local links and fragments resolve, and the filled pages work at desktop and phone widths. Check headings, code/table overflow, search results and keyboard navigation on the changed pages. Report editorial findings separately from compilation, rendering, and structural checks; passing those checks does not establish the quality of the prose.
## Template organization
diff --git a/documents/templates/partials/site.search.tmpl.partial b/documents/templates/partials/site.search.tmpl.partial
index b6ceae68..8c02395b 100644
--- a/documents/templates/partials/site.search.tmpl.partial
+++ b/documents/templates/partials/site.search.tmpl.partial
@@ -15,7 +15,7 @@