Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial font size is wrong when launched on external display #3900

Closed
zasdaym opened this issue Jun 26, 2023 · 4 comments
Closed

Initial font size is wrong when launched on external display #3900

zasdaym opened this issue Jun 26, 2023 · 4 comments
Labels
bug Something isn't working macOS Issue applies to Apple macOS waiting-on-op Waiting for more information from the original poster

Comments

@zasdaym
Copy link

zasdaym commented Jun 26, 2023

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20230408-112425-69ae8472

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

The initial font size is wrong when launching on an external display (27 inches, 2K resolution). After doing one of these actions the font size is corrected:

  1. Resizing the window
  2. Changing the font size via keyboard shortcut

To Reproduce

  1. Use the configuration provided below
  2. Open on a external display
  3. The font size will be too big
  4. Try resizing the window, the font size will be corrected

Configuration

local wezterm = require 'wezterm'

return {
  font = wezterm.font("Berkeley Mono"),
  font_size = 14,
  front_end = "WebGpu",
  hide_tab_bar_if_only_one_tab = true,
  initial_cols = 180,
  initial_rows = 50,
}

Expected Behavior

The font size is correct when launched on an external display.

Logs

No response

Anything else?

No response

@zasdaym zasdaym added the bug Something isn't working label Jun 26, 2023
@wez wez added the macOS Issue applies to Apple macOS label Jul 10, 2023
wez added a commit that referenced this issue Feb 7, 2024
There are a number of open issues that relate to getting the dpi
wrong when spawning a window. In theory it shouldn't matter because
we will immediately realize the difference and synthesize the correct
information, but evidence shows this isn't quite true.

What this commit does is:

* Override Connection::default_dpi() on macOS to return the
  effective_dpi from the active screen instead of the default
  non-retina dpi
* Adjust the Config::initial_size() method to accept an optional
  cell pixel dimension
* Add a helper function to wezterm-gui to compute the cell pixel
  dimensions given the config and the (usually default) dpi, and
  feed that through to Config::initial_size
* in the macos window impl, scale the computed geometry based on
  the ratio of the Connection::default_dpi and the default non-retina
  dpi.

This helps to avoid needing to do a fixup in the
#4966 case, and may help with
the various other macos quirky issues.

refs: #2958
refs: #3575
refs: #3900
refs: #4250
refs: #4285
refs: #4447
refs: #4851
refs: #4966
@wez
Copy link
Owner

wez commented Feb 8, 2024

Please try the latest nightly build and let me know if this is still an issue!

@wez wez added the waiting-on-op Waiting for more information from the original poster label Feb 8, 2024
Copy link
Contributor

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Copy link
Contributor

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working macOS Issue applies to Apple macOS waiting-on-op Waiting for more information from the original poster
Projects
None yet
Development

No branches or pull requests

2 participants