Repository navigation
Windows: dictation HUD often presents no frame or freezes its trace (NVIDIA RTX 3070 Ti, Dx12) #1793
Description
What happens
On Windows, the dictation HUD often doesn't show or animate. Dictation itself still records, transcribes, and pastes, but it feels janky:
- Some dictations show no HUD at all.
- When the HUD does show, the Dot scope trace (the waves) often doesn't react to speech vs. silence. The overlay looks stuck.
- Settings › General › Status then shows:
Last dictation failed: The recording HUD can't show (shown but presented no frame in 1500 ms; surface: Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm). Dictation still works.
This looks like the same failure as #1778 (AMD Radeon 760M, integrated, dev-1007), but here it happens on a discrete NVIDIA GPU. So it doesn't seem to be specific to one GPU vendor.
Environment
- OS: Windows 11 Home 10.0.26300 (x64)
- GPU: NVIDIA GeForce RTX 3070 Ti (discrete). The HUD draws on wgpu Dx12; the speech model runs on Vulkan on the same GPU.
- Hex: dev channel, direct install. Seen on 0.0.0-dev-1001 and 0.0.0-dev-1009. It seems to happen more often since 1001.
- Shortcut: Ctrl+Shift+Space, Hold mode
- Model: Parakeet Unified English (streaming on GPU)
Logs (%LOCALAPPDATA%\hex\logs\process.log)
Both failures happened when a new dictation started within about 1–2 s of the previous one finishing. The HUD was still closing or had just closed:
# running 0.0.0-dev-1001
16:26:01.069 INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
16:26:01.076 INFO hex::rune_hud: dictation HUD surface surface=Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm
16:26:30.043 INFO hex::windows::dictation: completed Windows dictation job audio_ms=29000 latency_ms=406
16:26:32.390 ERROR hex::rune_hud: dictation HUD can't show reason=shown but presented no frame in 1500 ms; surface: Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm
16:26:41.527 INFO hex::transcription::engine: finished live stream audio_ms=10869 ... # next dictation started at ~16:26:30.6
# running 0.0.0-dev-1009
16:38:34.686 INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
16:38:39.301 INFO hex::windows::dictation: completed Windows dictation job audio_ms=4380 latency_ms=303
16:38:51.116 ERROR hex::rune_hud: dictation HUD can't show reason=shown but presented no frame in 1500 ms; surface: Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm
16:39:02.393 INFO hex::transcription::engine: finished live stream audio_ms=13160 ... # next dictation started at ~16:38:49.2
HUD draws gpu=… is logged again before many dictations (16:35:09, 16:38:34, 16:39:42, 16:40:21, 16:40:56). It looks like the HUD's GPU device or surface is rebuilt for each dictation. A failed or slow rebuild may explain both the missing first frame and the frozen trace.
Other things logged in the same sessions (may not be related):
WARN hex::audio::overloads: microphone stream glitched; continuingWARN hex::transcription::engine: live stream unusable; transcribing the full clip reason=the stream received ~315 ms past the clip's end. This happened on about half the dictations.
Steps to reproduce
- Windows 11 with an NVIDIA GPU, dev channel (1001–1009).
- Dictate with the hold shortcut, release, and start the next dictation within about 1–2 s.
- Repeat. Sometimes the HUD doesn't appear or its trace doesn't move, and Status shows the error above.
Expected
The HUD shows on every dictation, and its Dot scope trace follows the microphone level.
Activity
maharshi365 commentedon Nov 13, 2026
Correction to the version info above, from my update history (Windows' Compatibility Assistant list of executables that ran, plus Release run numbers; dev-N = run N−100):
7f54733e, built Nov 11) was my last good build. I used it until Nov 12, 11:35 PM EST.4793e168) was the first build where I saw this. The 16:26 UTC error above came from 1001, before the staged 1009 took over.Regression window:
7f54733e..4793e168. The main suspect is the Rune bump069ea6fc(#1661),a7cea169→d6715352. It also newly patcheswgpu-halwith Rune's fork. In that range, the Rune commits that touch overlay surfaces and presents:1a219d16Overlay: one turn decision, and a surface that is made, parked, hidden or live (r15)34c920b4overlay draw scheduling backoff (r89);eec851cbuncovering keeps a missed frame's retry (r252)d9b45a57present worker as explicit state machines (r41)223a965f(Windows: hovering the Hex window causes whole-screen VRR/G-SYNC brightness flicker on OLED #689) /9b2cb52b(Distinguish left and right modifiers in chord shortcuts (e.g. Right Command + Right Option) #710) Windows: CPU first frame, then the GPU takes overbf8a5982(macOS: Hex says "You're all set" while the speech model is still downloading #676) D3D12 aloneThe same build window also brought memory growth to 5+ GB while dictating (#1796), probably the same root cause. #1778 (AMD, dev-1007) also falls after this bump.
windows: stop the hud's first-frame check from hiding a hud that is u…
windows: stop the hud's first-frame check from hiding a hud that is u…
windows: stop the hud's first-frame check from hiding a hud that is u…
windows: stop the hud's first-frame check from hiding a hud that is u…
windows: stop the hud's first-frame check from hiding a hud that is u…
maharshi365 commentedon Nov 14, 2026
Upstream: anomalyco/rune#887 (an overlay's memory grows with animation on NVIDIA). I added the likely cause and a probe there: anomalyco/rune#887 (comment)
In short: since Rune #844 (in Hex's
069ea6fcbump, dev-1001), Windows swap chains hold one frame and wgpu no longer waits on the frame-latency object (DontWait). Windows wait throughwindow::slot, but overlays like the HUD never wait, so the HUD's frames pile up while it animates.A Hex build (dev-1027's commit
cdf38590) against Runed6715352plus a bounded 100 ms wait before the overlay acquires each frame:The HUD drew normally, and the wait never reached the 20 ms logging threshold. This is one run; more back-to-back runs to follow. The fix belongs in Rune (overlays taking a
window::slot); Hex would then bump its Rune pin.fix(windows): pace the dictation HUD to one frame per display frame
fix(windows): pace the dictation HUD to one frame per display frame
fix(windows): pace the dictation HUD at about 60 Hz (#1828)