## What happened

Brave (Origin build) exhibits stuttering/flickering rendering under Hyprland, affecting both video playback and Brave's own UI chrome (loading spinner, red progress bar) identically. Symptoms:

- The `<video>` element area sometimes goes fully transparent instead of showing a frame — the desktop wallpaper behind the Brave window is visible through it (confirmed via screenshot, attached).
- Brave's native loading spinner and top progress bar stutter/skip frames the same way, at the same time — not limited to video content.
- Audio playback is completely unaffected and continuous throughout.
- The window itself does not crash; the underlying process keeps running normally.

## Expected

Smooth video playback and UI rendering, matching behavior on other Wayland compositors.

## Steps to reproduce

1. Open Brave (Origin), navigate to any YouTube video (both a regular watch page and a YouTube Short reproduce it).
2. Let playback start (autoplay or manual).
3. Observe the video area and Brave's own loading UI elements for stuttering/transparency within the first several seconds.

## System details

Reproduced identically on two separate machines, both Omarchy, both Hyprland 0.56.2 (`efb50993780079460b0cbed1363e2166a2de1d9f`, built Aug 5 2026):

**Machine A** — Omarchy 4.0.1-1, CPU: 11th Gen Intel Core i9-11900K, GPU: hybrid — AMD (drives the only connected display) + NVIDIA RTX 3060 (compute-only, no display attached, driver 610.57.04). Brave Origin 151.1.93.138.

**Machine B** — Omarchy (same base), single AMD GPU only (no NVIDIA present at all). Brave Origin 151.1.93.138 (identical build).

## What I ruled out

- **GPU vendor mismatch**: on Machine A, Omarchy's `nvidia.lua` unconditionally sets `__GLX_VENDOR_LIBRARY_NAME`/`LIBVA_DRIVER_NAME` to `nvidia` whenever any NVIDIA GPU is present in the system (via `omarchy-hw-nvidia`), regardless of whether it's the GPU actually driving the display (it isn't, here — `boot_vga=0` on the NVIDIA card, `boot_vga=1` on AMD). Overrode this to `mesa`/`radeonsi` via a user Hyprland config — this is likely still a real, separate bug worth fixing (routing a compute-only GPU's driver into Wayland client GL/VA-API selection seems wrong regardless), but did **not** fully resolve the stutter, and Machine B has no NVIDIA GPU at all yet shows the identical symptom. So this isn't the (sole) root cause of the stutter itself.
- **`render:direct_scanout`**: already `false` by default on Machine A.
- **Hyprland "explicit sync" toggle**: searched `hyprctl descriptions` for anything sync-related; no such config option exists in 0.56.2 (only unrelated VRR/adaptive-sync and cursor-theme-sync entries).
- **`brave://gpu`**: hardware video decode reports as active/healthy with no relevant driver-bug-list entries or blocklist problems for decode (only an unrelated "accelerated video *encode* disabled" note). Full dump attached.

Given it reproduces identically across two different GPU vendor configurations (AMD-only vs. AMD+NVIDIA-hybrid) with the same Hyprland/Brave versions, this looks like a Hyprland-Brave (or Hyprland-Chromium generally) compositing/frame-delivery interaction rather than a GPU-driver-specific issue — but I wasn't able to pin down the exact mechanism from the client side.

## Attachments

- Screenshot showing the transparent video pane (desktop wallpaper visible through it): to attach.
- `brave://gpu` full diagnostics dump from Machine A: to attach.