AddUpdateViewport() overwrites per-window FramebufferScale every frame (mixed-DPI viewports render at wrong scale)

[lailoken]

Version/Branch of Dear ImGui:

1.93.0 WIP, docking branch (regression from 98a66d8, 2026-08-04)

Back-ends:

any backend implementing Platform_GetWindowFramebufferScale (observed with imgui_impl_sdl2 + imgui_impl_metal)

Compiler, OS:

macOS, mixed-DPI monitors (1x main + 2x secondary)

Full config/build information:

// (Copy from the next line. Keep the ``` markers for formatting.)

Dear ImGui 1.93.0 WIP (19292)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 4, sizeof(ImDrawVert): 20
define: __cplusplus=202002
define: __APPLE__
define: __GNUC__=4
define: __clang_version__=21.0.0 (clang-2100.1.1.101)
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
define: NDEBUG
IM_ASSERT: runs expression: KO. expand size: KO (MAYBE DISABLED?!) (?)
--------------------------------
io.BackendPlatformName: imgui_impl_sdl2 (2.32.70, 2.32.70) (cocoa)
io.BackendRendererName: imgui_impl_metal
io.ConfigFlags: 0x00000481
 NavEnableKeyboard
 DockingEnable
 ViewportsEnable
io.ConfigDpiScaleFonts
io.ConfigDpiScaleViewports
io.ConfigViewportsNoAutoMerge
io.ConfigViewportsNoDefaultParent
io.ConfigDockingWithShift
io.ConfigNavCaptureKeyboard
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00000C1E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 RendererHasVtxOffset
 RendererHasTextures
 RendererHasViewports
--------------------------------
io.Fonts: 5 fonts, Flags: 0x00000004, TexSize: 512,512
io.Fonts->FontLoaderName: stb_truetype
io.DisplaySize: 1.00,1.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 0.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 1.00
style.ItemSpacing: 6.00,3.00
style.ItemInnerSpacing: 4.00,2.00

Details:

Description:

98a66d8 added this line to the tail of AddUpdateViewport():

    viewport->FramebufferScale = g.IO.DisplayFramebufferScale; // Later overidden by Platform_GetWindowFramebufferScale() for platform having it

AddUpdateViewport() runs every frame for every window's viewport, and the tail runs for
existing viewports too, so this overwrites the per-window value each frame. The
"later overridden" part happens in UpdatePlatformWindows(), i.e. after Render() - so by
the time SetCurrentWindow() picks the pixel density and InitViewportDrawData() stamps
draw_data->FramebufferScale, every viewport carries the main viewport's scale instead of
its own. Before 98a66d8 the handler's value persisted across frames (nothing reset it), and
InitViewportDrawData() fell back to io.DisplayFramebufferScale only when the value was 0.

Symptom: with a 1x main monitor and 2x secondaries, dragging a viewport window onto a 2x
monitor renders all its content at half size (draw data built with scale 1.0 while the
renderer's drawable is 2x). The inverse setup renders at double size.

Steps to reproduce:

SDL2 (or any backend with Platform_GetWindowFramebufferScale) + viewports on macOS with
monitors of different scales; drag a window from the main monitor to one with a different
scale.

Fix: initialize only on viewport creation, keeping the intent of the original comment —
plus a fallback for the viewports-disabled case:

    else
    {
        // New viewport
        ...
        viewport->DpiScale = GetViewportPlatformMonitor(viewport)->DpiScale;
        viewport->FramebufferScale = g.IO.DisplayFramebufferScale; // Later overidden by Platform_GetWindowFramebufferScale() for platform having it
    }

    viewport->Window = window;
    if (!(g.ConfigFlagsCurrFrame & ImGuiConfigFlags_ViewportsEnable))
        viewport->FramebufferScale = g.IO.DisplayFramebufferScale;
    viewport->LastFrameActive = g.FrameCount;

The fallback is required: the main viewport is created in Initialize() with
FramebufferScale = (0,0) (memset) and never passes through the new-viewport branch of
AddUpdateViewport(), and Platform_GetWindowFramebufferScale() is only polled when
viewports are enabled. Without it, any app running without ImGuiConfigFlags_ViewportsEnable
stamps draw_data->FramebufferScale = (0,0) (InitViewportDrawData() no longer falls back to
io.DisplayFramebufferScale since 1.93), so every renderer backend hits its
fb_width <= 0 early-out and the window renders blank.

(An alternative would be applying the Platform_GetWindowFramebufferScale() value during
UpdateViewportsNewFrame() rather than in UpdatePlatformWindows(), so it is fresh at the time
draw data and pixel density consume it.)

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

[ocornut]

(An alternative would be applying the Platform_GetWindowFramebufferScale() value during UpdateViewportsNewFrame() rather than in UpdatePlatformWindows(), so it is fresh at the time draw data and pixel density consume it.)

Platform_GetWindowFramebufferScale() is already called during UpdateViewportsNewFrame().
The problem is that at the time of Begin() we don't have the info for the first frame

Your suggested fix would leave main viewport's FramebufferScale zero for the first frame when viewports are enabled.
It might not be noticeable if asserts are disabled.

Pushed a fix 91b131e.
It's not perfect: spawning a new viewport on a different with a different scale as the default will run with a different scale for one frame (the non-visible frame likely). The problem is that practically all API provide the backing scale given a window not given a monitor. I believe our best best is to catch last known fb scale per monitor and reuse that.

I'm keeping this open because I'd like to aim to simulate those concepts in the test engine viewport emulator so I can repro cross platform.

[lailoken]

Tried your version - it fixes the secondary viewport case (per-window scale survives the frame, mixed-DPI dragging renders correctly again).

One edge case found while testing: the main viewport is created in Initialize() with FramebufferScale (0,0) and the UpdatePlatformWindows() handler loop starts at i = 1, so v
iewport 0 is never updated by Platform_GetWindowFramebufferScale(). Your guard seeds it once from io.DisplayFramebufferScale and then never refreshes it: if the main OS windo
w later moves to a monitor with a different scale, io.DisplayFramebufferScale follows the window but viewport->FramebufferScale stays stale. The same applies when viewports a
re disabled (the handler is not polled at all, and since 1.93 InitViewportDrawData() no longer falls back to io.DisplayFramebufferScale).

Suggestion:

    if (viewport->FramebufferScale.x <= 0.0f || viewport->ID == IMGUI_VIEWPORT_DEFAULT_ID)
        viewport->FramebufferScale = g.IO.DisplayFramebufferScale;

io.DisplayFramebufferScale is by definition the main window's scale (backends re-query it every frame), so viewport 0 can simply track it while Platform_GetWindowFramebufferS
cale() owns the others.

[lailoken]

Correction to my previous comment: with viewports enabled, viewport 0 is fine - the UpdateViewportsNewFrame() loop polls Platform_GetWindowFramebufferScale() for it every frame (PlatformWindowCreated is true from Initialize()), so no staleness there. My remaining concern is only the viewports-disabled case: the handler block is skipped, so after 91b131e the main viewport keeps its first-frame scale forever, and InitViewportDrawData() no longer falls back to io.DisplayFramebufferScale when the window moves to a monitor with a different scale.

Possibly related: UpdateViewportsNewFrame() computes main_viewport_framebuffer_scale (including the preserve-when-minimized branch, parallel to pos/size) but never applies it anywhere. Applying it to main_viewport->FramebufferScale after the AddUpdateViewport() call looks like it may have been the intent, and would cover the viewports-disabled case.

[ocornut]

Pushed a fix 035c87e + tidying up 94c05ba.