brndnmtthws / conky

Light-weight system monitor for X, Wayland (sort of), and other things, too
https://conky.cc
GNU General Public License v3.0
7.27k stars 620 forks source link

[Bug]: `use_xft = true` breaks window sizing #1528

Closed simotek closed 6 months ago

simotek commented 1 year ago

What happened?

Window sizing is smaller when use_xft = true is set then when it is not, if a window is a forced size with min_width and max_width being the same then the window size will be slightly smaller then that.

This first image is with use_xft=true the colored temperature shape should be centered shot-2023-05-09_18-54-42

This second shot is showing everything working properly with it disabled shot-2023-05-09_18-55-23

Issue is seen running a few day old version of conky from git on openSUSE Tumbleweed

Version

git

Which OS/distro are you seeing the problem on?

Linux (other)

Conky config

https://github.com/philer/polycore  `/opt/conky/bin/conky -c  conkyrc.lua` I had to comment out line 45 of layout.lua to stop a crash as I don't have gpu support.

Stack trace

No response

Relevant log output

No response

Caellian commented 6 months ago

My guess was that font size (glyph width) gets used for window width calculation somehow, but that's not the case.

Closing for now as I can't reproduce (Openbox) with:

conky.config = {
  own_window = true,
  own_window_type = 'override',
  own_window_hints = 'undecorated,sticky,skip_taskbar,skip_pager',
  minimum_width = 500,
  maximum_width = 500,
  use_xft = true,
  font = 'Ubuntu:pixelsize=200',
}
conky.text = [[
  $conky_version
  $conky_version
  $conky_version
]]

Not sure if I'm missing something, but use_xft doesn't have any interaction with window size (besides making it larger if maximum_width not set).

Reopen the issue if you still have it and add which WM you're using.

Caellian commented 6 months ago

Nvm, reopening the issue, you can close it if it's fixed. Try it with minimal example so we can tell whether something else is at play as well (templates?).

Caellian commented 6 months ago

I believe I found what causes this.

In configure event handler there's this:

int mw = surface->dpi_scale(maximum_width.get(*state));
if (text_width > mw && mw > 0) { text_width = mw; }

I don't think expected width in pixels should be affected by DPI. So even though it doesn't affect min_width, by affecting max_width it shrinks the window.

surface->dpi_scale is defined as:

int display_output_x11::dpi_scale(int value) {
#if defined(BUILD_XFT)
  if (use_xft.get(*state) && xft_dpi > 0) {
    return (value * xft_dpi + (value > 0 ? 48 : -48)) / 96;
  } else {
    return value;
  }
#else  /* defined(BUILD_XFT) */
  return value;
#endif /* defined(BUILD_XFT) */
}

There's a few things that might be improved:

... and there I was, eagerly closing issues :fearful:

Caellian commented 6 months ago

Let me know if the issue needs to be reopened. I believe the linked PR fixes it.