fix: wait for DirectWrite font subsystem before starting at logon#1
Merged
Conversation
When launched at logon via the HKCU Run key, the app could fail with a system-modal "Failed to launch" error box and never start, while a manual launch always worked. gpui::Application::new() constructs WindowsPlatform::new(), which creates a shared DirectWrite factory (DWriteCreateFactory(DWRITE_FACTORY_TYPE_SHARED)) and enumerates the system font collection (GetSystemFontCollection). Both depend on the Windows Font Cache Service, which is often still starting in the first seconds of a session, so those calls fail and GPUI panics after showing the error box. Waiting for Shell_TrayWnd is not sufficient because it can appear before the font subsystem is ready. Add boot::wait_for_font_subsystem(), called right before gpui::Application::new(), which probes the same DirectWrite calls with backoff (~30s) until they succeed and logs late readiness/failures to %APPDATA%\Polterdesk\startup.log. On a warm machine the probe succeeds on the first attempt, so there is no added startup latency. The tray thread is spawned before the wait so the tray icon still appears promptly at boot.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Starting the app at Windows logon (via the HKCU
Runkey) could fail with a system-modal "Failed to launch" error box, after which the app never starts. A manual launch always worked.Root cause
gpui::Application::new()constructsWindowsPlatform::new(), which creates a shared DirectWrite factory (DWriteCreateFactory(DWRITE_FACTORY_TYPE_SHARED)) and enumerates the system font collection (GetSystemFontCollection). Both depend on the Windows Font Cache Service, which is frequently still starting in the first seconds of a logon session. When they fail, GPUI shows aMB_ICONERROR | MB_SYSTEMMODALbox and then.unwrap()panics, so the process aborts. The existingwait_for_shell()only waits forShell_TrayWnd, which can appear before the font subsystem is ready.Fix
Add
src/boot.rswithwait_for_font_subsystem(), called right beforegpui::Application::new(). It probes the same DirectWrite calls with backoff (120 × 250 ms ≈ 30 s) until they succeed, and logs late readiness / timeout to%APPDATA%\Polterdesk\startup.log. On a warm machine the probe succeeds on the first attempt, so there is no added startup latency. The tray thread is spawned before the wait so the tray icon still appears promptly at boot.Tests
tests/boot_test.rscovers the retry harness (poll_until_ready) deterministically with an injected probe.Verification
cargo clippy -- -D warnings— cleancargo build --release— buildscargo test --test boot_test— 4 passedThe boot-time fix itself is best confirmed with a reboot (autostart enabled).