Sprint 208: Asynchrones Asset-Streaming & Background WGPU Queue Worker 🚀
Willkommen zu Sprint 208! Wir haben einen entscheidenden Meilenstein für Echtzeit-3D-Rendering erreicht: das Eliminieren von Framerate-Rucklern beim Laden großer Grafikdaten. Durch die Einführung von asynchronem Asset-Streaming bleibt der WGPU-Hauptthread völlig flüssig, während schwere I/O-Lesezugriffe und die Bilddecodierung in Hintergrund-Threads ausgelagert werden.
⚡ Nicht-blockierendes Laden von Texturen
Zuvor blockierte der Aufruf von registry_load_texture(path) den Hauptthread, während die Bilddatei geöffnet und decodiert wurde. In Echtzeit-3D-Umgebungen führte dies zu spürbaren Rucklern (Frame Drops).
In Sprint 208 wurde das Laden komplett asynchron gestaltet:
- Der FFI-Aufruf erhöht einen atomaren Zähler (`TEXTURE_ID_COUNTER`) und gibt die Textur-ID sofort an das Skript zurück, ohne zu blockieren.
- Die eigentliche Arbeit — das Lesen der Datei und das Decodieren in einen rohen RGBA-Byte-Buffer — wird in einem Hintergrundthread via
std::thread::spawnausgeführt.
⚙️ Verzögerte GPU-Injektion
Sobald der Hintergrundthread die Decodierung abgeschlossen hat, sendet er den rohen Pixelpuffer über den Renderkanal zurück an den Haupt-Renderthread: RenderCommand::LoadTexture { id, width, height, rgba }.
Der Hauptthread liest den Befehl asynchron im nächsten Frame aus und schreibt die Texturdaten über WGPU-Queues in den VRAM der GPU. Da die Bilddecodierung somit parallel auf anderen CPU-Kernen läuft, bleibt der Hauptthread vollkommen ruckelfrei!
🧪 Verifizierung & Testabdeckung
Zur Absicherung wurde der Integrationstest test_asset_streaming_non_blocking in `tests/sandbox_tests.rs` integriert. Dieser simuliert das gleichzeitige Laden von fünf Texturen, stellt sicher, dass die IDs sofort zugewiesen werden und die Gesamtzeit unter 200 ms bleibt, womit das asynchrone Ausführungsmodell bewiesen ist.