Skip to content

perry-ui-windows: BloomView child HWND is DPI-scaled inside an unscaled top-level window (content draws partially out of view) #5884

Description

@proggeramlug

Found while verifying #5812 on a Windows 11 x64 box with a 2560×1440 display at >100% scaling.

Symptom: App({ width: 800, height: 600, body: BloomView(800, 600) }) produces a top-level window whose rect is 800×600 physical pixels (not DPI-scaled), while the BloomView child HWND gets laid out to ~1178×844 physical (DPI-scaled, and not even uniformly — 1178/800 ≈ 1.47 horizontal vs 844/600 ≈ 1.41 vertical). The child spills past the parent's client area, so any content it draws (e.g. a wgpu swapchain image, which DXGI stretches over the full child rect) is mostly clipped out of view — in the #5812 triangle repro only the top-left of the scene is visible and the triangle sits outside the window.

Evidence (from PERRY_WEBGPU_DIAG=1 window-state logging in PerryTS/webgpu#2):

top-level window rect: (203,203)-(1003,803)   = 800×600 physical
BloomView child rect:  (315,349)-(1493,1193)  = 1178×844 physical

Expected: parent and child agree on units — either both logical (DPI-aware window sized 1200×900 physical at 150%, child filling it) or both physical.

Where to look: crates/perry-ui-windows/src/app.rs CreateWindowExW size vs app_set_body's MoveWindow/layout_widget path, and dpi_compat.rs; BloomView's set_fixed_width/height values appear to get DPI-multiplied somewhere the top-level size does not.

Repro app: the #5812 triangle test (BloomView as direct App body) on any >100% DPI display.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugConfirmed defect or regression

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions