emilk/egui · error

viewport doesn't exist

Error message

viewport doesn't exist

What it means

`GlowIntegration::initialize_window` looks up the viewport by `viewport_id` in `self.viewports` and `.expect`s it to exist. If a caller (e.g. `initialize_all_windows`) requests initialization of a viewport id that was never registered — or that was removed — the library panics with 'viewport doesn't exist'. This is an internal invariant: all viewports to initialize must already be tracked.

Source

Thrown at crates/eframe/src/native/glow_integration.rs:1266

            if let Err(err) = self.initialize_window(viewport_id, event_loop) {
                log::error!("Failed to initialize a window for viewport {viewport_id:?}: {err}");
            }
        }
    }

    /// Create a surface, window, and winit integration for the viewport, if missing.
    #[expect(unsafe_code)]
    pub(crate) fn initialize_window(
        &mut self,
        viewport_id: ViewportId,
        event_loop: &ActiveEventLoop,
    ) -> Result {
        profiling::function_scope!();

        let viewport = self
            .viewports
            .get_mut(&viewport_id)
            .expect("viewport doesn't exist");

        let window = if let Some(window) = &mut viewport.window {
            window
        } else {
            log::debug!("Creating a window for viewport {viewport_id:?}");
            let window_attributes = egui_winit::apply_monitor_to_window_attributes(
                egui_winit::create_winit_window_attributes(
                    &self.egui_ctx,
                    viewport.builder.clone(),
                ),
                &viewport.builder,
                event_loop,
            );
            if window_attributes.transparent()
                && self.gl_config.supports_transparency() == Some(false)
                && !cfg!(target_os = "windows")
            {
                log::error!("Cannot create transparent window: the GL config does not support it");

View on GitHub (pinned to 441971a776)

Solutions

  1. Update eframe/egui to matching versions — stale viewport ids across mismatched egui/eframe versions commonly trigger this.
  2. If you maintain a fork, replace the `.expect` with a `let Some(viewport) = self.viewports.get_mut(&viewport_id) else { return Ok(()) }` skip-and-log.
  3. Make sure viewports closed during a frame are removed from any pending-initialization list before `initialize_all_windows` runs.
  4. Avoid caching `ViewportId`s across frames; derive the set to initialize from the current `self.viewports` snapshot.

Example fix

// before (fork/internal)
let viewport = self.viewports.get_mut(&viewport_id).expect("viewport doesn't exist");
// after
let Some(viewport) = self.viewports.get_mut(&viewport_id) else {
    log::debug!("viewport {viewport_id:?} no longer exists; skipping initialization");
    return Ok(());
};
Defensive patterns

Strategy: type-guard

Type guard

// defensive pattern for code iterating viewports before eframe initializes them
fn is_known_viewport(viewports: &std::collections::HashMap<egui::ViewportId, Viewport>, id: &egui::ViewportId) -> bool {
    viewports.contains_key(id)
}

Try / catch

// this is an internal panic, not a Result; guard at the fork/integration layer:
// replace `.expect("viewport doesn't exist")` with get_mut + early return, and log the stale id.

Prevention

When it happens

Trigger: Calling `initialize_window(viewport_id)` for an id not present in `self.viewports`; viewport state cleared/rebuilt between listing and initialization; custom code or patches injecting viewport ids that don't match registered ones.

Common situations: Multi-viewport apps where a viewport was closed (viewport info removed from egui) while pending initialization; stale viewport ids cached across frames; races between egui's viewport list and eframe's map.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of emilk/egui@441971a776 (2026-09-12). Data as JSON: /api/errors/4cac85083bfa627a. Report an issue: GitHub.