Skip to content

Desktop app appears too small on high-DPI displays on Windows/Linux #861

Description

@SuperComboGamer

Summary

On Windows and Linux, the desktop app does not automatically scale its UI on high-DPI displays the way macOS does. On 1440p and especially 4K monitors, the app can appear extremely small and difficult to use.

Problem

Electron does not automatically handle high-DPI scaling for this app on Windows in the same way macOS handles Retina displays. As a result:

  • 1080p looks normal
  • 1440p can look undersized
  • 4K can look tiny

This is especially noticeable when moving the app between monitors with different DPI / scaling characteristics.

Expected behavior

The desktop app should automatically scale its UI based on the current display so that it remains comfortably usable on high-DPI monitors.

Proposed behavior

  • Automatically detect display resolution / effective display size
  • Apply a zoom baseline for high-DPI monitors
  • Keep 1080p unchanged
  • Recompute scaling when windows are created or moved between monitors
  • Preserve manual user zoom adjustments instead of overwriting them
  • Allow reset back to the display-based automatic zoom level

Notes

  • This should only apply to Windows and Linux
  • macOS should remain unchanged, since Retina / HiDPI behavior is already handled well there
  • Multi-monitor setups should be supported so the zoom baseline updates correctly per display

Related

Proposed fix is available in PR #406.

Activity

  1. EndreEndi commented on Mar 24, 2026

    @EndreEndi

    A small thing i have to say, can someone add a button to manually change the scaling? i have issues with my eyes and i can't see anything without 200% zoom..

  2. mi-ael commented on Jul 12, 2026

    @mi-ael

    i use t3-code-desktop --force-device-scale-factor=1.5 as a workarround

  3. CarlosJunioor commented on Aug 4, 2026

    @CarlosJunioor

    Another data point from Windows, and one that is not strictly a DPI problem.

    I am on Windows 11 with a 5120x1440 ultrawide. That is roughly 109 PPI, so display-based auto-detection would classify it as a normal-density monitor and leave it alone, but the UI is still too small for me to read at the default. At that width the app spreads across a lot of physical space while the type stays at its base size, so the practical outcome is the same as the high-DPI case described here. I would want somewhere around 35 to 50 percent larger.

    The existing zoom does not get me there. Ctrl and = does nothing for me in the desktop app, which looks like the same failure as #4627, and there is no menu bar visible on Windows to reach View and Zoom In another way. There is also nothing in Settings that mentions text or UI size, so there is no discoverable path to a larger UI at all. The only remaining option I could find is the --force-device-scale-factor launch flag mentioned above, which means editing a shortcut target.

    That makes the "preserve manual user zoom adjustments" bullet in the original post worth widening slightly: expose the scale as a plain persisted value in Settings, alongside the auto-detected baseline. A number in Settings survives restarts, is discoverable without knowing a shortcut exists, and sidesteps the keybinding problems in #4627 and #2706 entirely rather than depending on a working accelerator.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions