Windows: default window and UI feel oversized on high-DPI displays

[ananthan199601]

On Windows, AltSendme appears noticeably larger than on macOS. The default window size (1024×680) combined with Windows display scaling makes the app feels like taking up lot of space than required on common laptop setups (e.g. 1080p at 125–150% scaling), while the same build on macOS looks appropriately sized.

Environment

• OS: Windows 10/11 with display scaling ≥ 125% (often 150% on 13–15" 1080p laptops)
• App: Tauri desktop build, default window from tauri.conf.json: 1024×680
• Comparison: macOS (Retina) with same default window config

Steps to reproduce

1. Run AltSendme on Windows with system display scaling set to 125% or 150%.
2. Launch the app with default window settings (no manual resize).
3. Compare visually with macOS on a typical laptop display.

Expected behavior

Initial window size and UI density should feel similar across platforms - reasonable margins around the window, not nearly fullscreen on a 1080p display.

Actual behavior

• The window occupies most of the screen height (e.g. at 150% scaling, 680 × 1.5 ≈ 1020 physical pixels on a 1080p screen ≈ 94% of vertical space).
• UI feels oversized / cramped relative to macOS.

Technical context

Tauri specifies window dimensions in logical pixels. On Windows:

physical size ≈ logical size × scale_factor

So the configured 1024×680 window becomes much larger in physical pixels at 125–200% scaling. WebView2 also applies DPI scaling to web content, while the UI uses fixed sizing (px / rem from a fixed base font). That combination makes the issue worse than in a normal browser tab, where content adapts to the viewport instead of a fixed native window.

Platform	Typical case	Effect
macOS	Retina, logical points	1024×680 feels ~50–60% of screen height
Windows	1080p @ 150%	Same logical size → ~94% of screen height

Shrinking only the window frame without adjusting content scale leaves the UI at the same density inside a smaller chrome - the problem is window footprint + content density under Windows DPI, not macOS being incorrectly sized.

Possible directions

1. Preferred long-term: More responsive layout (relative units, flexible min window size) instead of relying on a fixed 1024×680 assumption.
2. Pragmatic: Windows-only startup adjustment using monitor scale_factor (initial window size and/or webview zoom), with tuning so it doesn’t feel too small or too large.

Happy to help test or share a prototype patch if useful.