A Bug(?) Regarding baseview and Windows DPI Settings

WarningAI Coding

This article features AI coding.

Background

I was creating a spectral phase locker effect (will be released soon, I hope). First I wanted to create it in plugdata, and I DID succesfully created it; however, I noticed that plugdata is really buggy, especially regarding the issues of parameters saved (incorrectly) in DAW, making it actually unusable.

So, I decided to use nice-plug to reconstruct the whole thing. However, I don’t have any experience in coding with it; so, I used an AI (deepseek-v4-pro) agent to do it.

After a while, AI successfully recreated it; however, there’s a really hard bug, stated below.

Issue

I noticed that the canvases are always exceeding the actual window area, almost about 1/4 of their total width. After a long debugging session, AI started to notice the DPI settings.

It turned out that, and I quote:

Fix 18: DPI viewport mismatch — resolution

• Root cause (confirmed in source)

baseview-0.2.2/src/platform/win/window.rs:440-442:

let scaling_factor = match options.scale  {
    WindowScalePolicy::SystemScaleFactor => 1.0,  // <-- HARDCODED 1.0
    WindowScalePolicy::ScaleFactor(scale) => scale,
};
let window_size = options.size.to_physical(scaling_factor); // 1100×800 physical

iced_baseview-0.4.0/src/shell/mod.rs:179-182:

let scale = match settings.window.scale {
    WindowScalePolicy::ScaleFactor(scale) => scale,
    WindowScalePolicy::SystemScaleFactor => window_scale_factor,  // actual DPI (1.5)
};
let physical_size = settings.window.size.> to_physical(scale); // 1650×1200 physical

HWND = 1100×800 physical. Viewport renders at 1650×1200 physical into a 1100×800 framebuffer → 1.5× overflow of everything: sliders, canvases, all content.