# M2 — nativer wgpu-2D-Renderer im Tauri-Fenster: Ansatzwahl

> Ziel: den bereits fluessig laufenden standalone `render2d`-Renderer aus dem
> ECHTEN Tauri-Prozess heraus mit nativer GPU-Performance anzeigen — nicht in der
> WebKitGTK-Webview (Perf-Flaschenhals), nicht in einem Chromium-Workaround.
> Maschine: Linux, Wayland, AMD.

## Gewaehlter Ansatz: **B — separates natives Fenster (winit) im Tauri-Prozess**

Der Tauri-Hauptthread haelt weiterhin die GTK-Hauptschleife + das Webview-Fenster
(HTML-Chrome). Aus dem Tauri-`setup`-Hook startet der Prozess auf einem
Hintergrund-Thread ein **eigenes natives winit-Fenster** mit eigener wgpu-Surface,
das die `render2d`-Demo-Szene (konkaves L + Raum + Papier-mm-Linien) rendert,
pan-/zoombar. Renderer/Szene werden NICHT reimplementiert — es ist exakt der Code
des verifizierten standalone `spike`-Bins (`render2d::gpu::Renderer` +
`render2d::demo_scene`).

### Warum B (und was gegen A/C spricht)

- **Kein geteilter Wayland-Surface → keine Contention/Flicker.** winit spricht auf
  Linux DIREKT Wayland/X11 (Crates `wayland-client`/`x11rb`), es benutzt **kein
  GTK**. Das native Fenster bekommt eine eigene, von WebKitGTK voellig getrennte
  Wayland-Surface. Genau das umgeht das dokumentierte Problem aus der Vorrecherche
  (Roh-wgpu-Surface UNTER der Webview im selben Fenster → Flicker/Schwarzbild auf
  Wayland).
- **Zwei Fenster-Stacks, aber KEIN Event-Loop-Konflikt.** tao (Tauri) fuehrt eine
  GTK-Hauptschleife auf dem Hauptthread; winit fuehrt eine eigene Schleife.
  winit 0.30 erlaubt die Event-Loop explizit auf einem Nicht-Haupt-Thread via
  `EventLoopBuilderExtWayland::with_any_thread(true)` (X11-Pendant analog). Der
  native Renderer laeuft daher auf `std::thread` „cad-native2d", der Tauri-/GTK-
  Hauptthread bleibt frei. Da winit nicht an GTK gebunden ist, kollidieren die
  beiden Schleifen nicht (getrennte Stacks, getrennte fds).

- **Ansatz A (wgpu-Surface im SELBEN Tauri-Fenster, Unter-/Overlay):** verworfen.
  taos `raw_window_handle_rwh_06()` liefert auf Wayland den `WaylandWindowHandle`
  der GTK-`ApplicationWindow` — also DIESELBE Surface, in die WebKitGTK
  komponiert. Eine zweite wgpu-Surface darauf ist genau die Contention, die die
  Vorrecherche als flackernd/schwarz auf diesem Setup markiert hat. Hoechstes
  Wayland-Risiko, fuer den Spike ungeeignet.
- **Ansatz C (wgpu als Haupt-Surface, HTML nur duennes Overlay):** verworfen fuer
  den Spike. Sauberste Perf-Story, aber groesster Umbau: die ganze App muesste auf
  eine winit/tao-getriebene Haupt-Schleife umziehen und die Tauri-Webview zur
  Nebenrolle degradiert werden. Kein „minimaler realer Spike" mehr. Bleibt die
  Ziel-Endarchitektur-Option, aber nach B.

## Crates / Versionen (verifiziert aus der Lock-Datei)

| Rolle | Crate | Version |
|---|---|---|
| Tauri | `tauri` / `tauri-runtime-wry` | 2.11.5 / 2.11.4 |
| Fenster (Webview-Seite) | `tao` | 0.35.3 |
| Webview | `wry` | 0.55.1 |
| Natives Renderfenster | `winit` | 0.30.13 |
| GPU | `wgpu` / `wgpu-hal` | 22.1.0 / 22.0.0 |
| Handle-Bruecke | `raw-window-handle` | **0.6.2 (identisch fuer tao UND wgpu/winit)** |
| Renderer | `render2d` (Pfad) | 0.1.0, Feature `window` |

Der entscheidende Kompatibilitaets-Glueckstreffer: tao 0.35 und wgpu 22/winit 0.30
teilen sich `raw-window-handle 0.6.2` — keine rwh-Versionsbruecke noetig. (Fuer
Ansatz B wird der tao-Handle gar nicht gebraucht, weil das native Fenster eine
eigene winit-Surface hat; die Versions-Parität ist aber die Voraussetzung fuer ein
spaeteres A/Compositing, falls je gewuenscht.)

## Wayland-Caveats (fuer den Start auf dieser Maschine)

- **`WEBKIT_DISABLE_DMABUF_RENDERER=1`** bleibt fuer die Webview-Sichtbarkeit auf
  diesem Wayland/AMD-Setup noetig (Vorrecherche). Betrifft die WebKitGTK-Seite,
  nicht das wgpu-Fenster.
- Das native winit-Fenster laeuft ueber Vulkan; GLES/EGL-Fallback wurde standalone
  ebenfalls funktionierend gesehen. `WGPU_BACKEND=gl` erzwingt bei Vulkan-Zicken
  den GL-Pfad.
- `with_any_thread(true)` ist zwingend — ohne die Freigabe panict winit, weil es
  die Event-Loop sonst nur auf dem Hauptthread zulaesst (den haelt hier GTK).

## Bau-Isolierung

Alles hinter Cargo-Feature **`native2d`** in `cad-tauri` (opt-in). Der normale
Build (`cargo build`, `npm run tauri:dev`) zieht weder winit noch wgpu und bleibt
unveraendert. `render2d` bleibt ohne Tauri-/GTK-Abhaengigkeiten headless baubar
und testbar.

## Naechster Schritt Richtung Vollbild-App (2D-Viewport + HTML-Chrome)

1. Szene aus dem echten Modell speisen: `Plan.primitives` (TS) → serde-`Scene` →
   ueber einen Tauri-`emit`/Command an den native2d-Thread (statt `demo_scene`).
2. Pan/Zoom-State zwischen Webview-Chrome und native2d-Fenster synchronisieren
   (Tauri-Events beidseitig).
3. Fenster-Kopplung: das native Fenster als Kind/als angedockten Bereich neben der
   Webview positionieren (Layout), spaeter ggf. Umstieg auf Ansatz C, wenn ein
   einziges Fenster gefordert ist.