I rewrote the code that determines the initial size altogether, so it might just be a difference in implementation. Here's how the current algorithm works, which would indeed be expected to produce the results you mention - though I'm open to making tweaks if desired, I don't by any means consider it "set in stone".
The window scale is calculated via the following rules (I've noted with an "HR" tag anything that's specific to high-resolution mode; if I have not made such a note, assume no difference, including that widths / heights are not scaled).
- Find the lesser of (screen width / 320) or (screen height / 200), round it down and subtract 1 from it
- Set the scale to the lesser of (the above), or (the user's zoom level) (HR: lesser of (the above), or (*double* the user's zoom level))
- If the scale is less than 1, set it to 1 (HR: if less than 2, set it to 2)
The window width is then set to 416 x the scale if using full-size panel, or 320 x the scale if using compact panel. The window height is set to 200 x the scale. Finally, the window is positioned such that it's centered on the screen.
I suspect it's specifically the "subtract 1" in the first step that's resulting in the result that you're finding unexpected. I put this here because I felt that on my screen (1920x1080), not having the -1 doesn't leave enough empty space around the sides of the window. Perhaps this could instead be addressed with a special case for 1920x1080 (or alternatively, keep the -1 and introduce a special case for 1366x768). At some point I should look at how well this works for all common resolutions, tbh, and decide from there.