Windows 11 + multi-monitor + mixed DPI. Maximising the app turns the whole board black; hovering a control repaints just that control while everything else stays black. The board also flickers continuously when idle and unmaximised. Dragging the window from the 4K 150%-scaled monitor onto a 3440×1440 100%-scaled monitor stops the flicker entirely (a black bar is left behind at the left edge). The same app version on macOS is unaffected.
CAUSE: src/main.js in the packaged asar enables Chromium's experimental Vulkan backend on every non-macOS platform:
app.commandLine.appendSwitch('enable-unsafe-webgpu');
if (process.platform !== 'darwin') {
app.commandLine.appendSwitch('enable-features', 'Vulkan');
}
The `!== 'darwin'` guard is precisely why macOS is unaffected and Windows is not. The comment block directly above that code states the switch was added as a guess at a WebGPU startup failure, that the guess was measured to be WRONG (the real fix was the three.js featureLevel:'compatibility' change in videoRenderer.js), that it was retained only because 'Windows and Linux back WebGPU through Vulkan and have not been tested', and it explicitly asks for the switch to be deleted if testing shows it unnecessary. This report is that test result: on Windows it is not harmless.
IMPORTANT CORRECTION TO THE EXISTING HYPOTHESIS: the comment on the child-process-gone handler calls a GPU-process crash 'the prime suspect for the black screen reports on Windows 11'. That is not what is happening here. The render-process-gone and child-process-gone handlers are correctly wired and logging, and they produced ZERO entries across main.log and main.old.log. There are zero [error] lines in main.log. The GPU process is alive and resident (~399 MB working set) while the window is black. This is a live GPU process presenting blank/stale frames from a broken Vulkan swapchain, not a process death that Chromium respawns. The auto-reload recovery path therefore never triggers, because nothing ever crashes – which is why the only way out is to unmaximise or move the window.
The 'hover makes one button appear, the rest stays black' behaviour is the signature of damage-rect-only presentation: the swapchain surface is blank and only invalidated regions get composited through.
WHY DPI IS THE TRIGGER: the renderer runs with –device-scale-factor=1.5 on the 4K primary. Maximising drives the surface to 3840×2160 device pixels and swapchain recreation fails. Moving the window to the 100%-scaled ultrawide changes the scale factor and shrinks the surface, and the symptom clears. This is a mixed-DPI swapchain-recreation path, so it should reproduce on any Windows machine running two monitors at different scaling factors.
SECONDARY FACTOR WORTH RULING IN OR OUT: the Windows-only branch in createWindow sets titleBarStyle:'hidden' with a titleBarOverlay. That overlay's geometry is recalculated on maximise and on DPI change – the same code path as the failure. macOS takes the hiddenInset branch instead. Both Windows-only differences sit on the maximise path, so it is worth testing them separately.
SUGGESTED FIX: drop the Vulkan switch on Windows, as the code comment already invites, or gate it behind a user-facing setting that defaults to off. Launching with –disable-features=Vulkan overrides it (Chromium's disable list takes precedence over the enable list) and is the workaround in use meanwhile.
Steps to reproduce
1. Run GreenLight DashBoard 10.2.0 on Windows 11 with two monitors at different DPI scaling (here: 3840×2160 @150% primary, 3440×1440 @100% secondary).
2. Open a board on the high-DPI monitor. Observe continuous flicker while idle, with no interaction at all.
3. Maximise the window. The entire board goes black.
4. Hover over toolbar controls. Each hovered control paints in isolation; everything else stays black.
5. Drag the window onto the 100%-scaled monitor. The flicker stops; a black bar remains at the left edge.
6. Check the logs: no render-process-gone, no child-process-gone, no [error] entries. The GPU process is still alive in Task Manager throughout.
Expected
The window composites normally when maximised and when moved between monitors with different DPI scaling, as it already does on macOS.
Actual
The window presents blank/black frames with damage-rect-only repaints while the GPU process stays alive. Continuous flicker on the high-DPI monitor when idle. No crash is logged, so no recovery path fires.
Error output
# Live process command lines (v10.2.0, Windows 11):
--type=gpu-process --gpu-preferences=... --enable-features=Vulkan
--disable-features=SpareRendererForSitePerProcess,WinDelaySpellcheckServiceInit,WinRetrieveSuggestionsOnlyOnDemand
--type=renderer --no-sandbox --no-zygote --enable-unsafe-webgpu
--video-capture-use-gpu-memory-buffer --device-scale-factor=1.5
--num-raster-threads=4 --enable-main-frame-before-activation --enable-features=Vulkan
# Source, resources/app.asar -> src/main.js (lines 34-37):
app.commandLine.appendSwitch('enable-unsafe-webgpu');
if (process.platform !== 'darwin') {
app.commandLine.appendSwitch('enable-features', 'Vulkan');
}
# Crash-handler output during the black-screen state:
(none - zero matches for 'Renderer process gone' / 'Child process gone' in main.log and main.old.log)
(zero [error] lines in main.log)
Context
Feature area: Electron shell / GPU compositing – not board or media specific, reproduces on any board.
App version: 10.2.0
Electron 33.4.11 / Chromium 130.0.6723.191
OS: Windows 11 Pro 10.0.26200
GPU: NVIDIA GeForce RTX 2070 SUPER, driver 32.0.15.9636 (2026-04-23)
Displays: LG 27in 4K primary at 150% scaling (renderer device-scale-factor 1.5); Samsung 34in 3440×1440 secondary at 100%, positioned to the left with a +117px vertical offset.
Unaffected platform: macOS, same app version (the Vulkan switch is skipped on darwin).
Environment
App version: 10.2.0
Platform: Windows 11 (AMD64)
