☰

Gnomeの分数スケーリングが1.75ではなく1.7518248558044434であるのはなぜですか？

tag-icon • tag-icon gnome display wayland
Gnomeの分数スケーリングが1.75ではなく1.7518248558044434であるのはなぜですか？

Gnome設定で175％ズームを設定すると、値は次の1.7518248558044434ように保存されます~/.config/monitors.xml。

<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1.7518248558044434</scale>
      <primary>yes</primary>
      <monitor>
        <monitor spec>
          <connector>DP-3</connector>

なぜですか？最初は浮動小数点丸めエラーが原因であると思いましたが、1.75は正確な値を表すことができる幸せな数値の1つです。

ドワーフウェイランド43.3

ベストアンサー1

事前設定された倍率（100％、125％など）は、解像度に対して水平および垂直に事前調整された仮想ピクセルの整数を提供する最も近い値に調整されます。 1.7518248558044434 値であると判断した場合、これはおそらく 2192 x 1233 仮想です。解像度があり、3840 x 2160モニターがあります。

この値で計算された幅が小数点4桁までだけ正確な理由は、単精度浮動3840/1.7518248558044434 = 2191.9999520937613小数点（IEEE-754 32ビット）でスケールを変換したようです。倍精度近似値3840/2192はに似ています1.7518248175182483が、値を単精度に変換してから再度倍精度に変換すると、1.7518248558044434正確な値が得られます。答えが示唆したように、Pythonでこれを行いました。 https://stackoverflow.com/a/43405711/60422:

>>> struct.unpack('f', struct.pack('f', 1.7518248175182483))[0]
1.7518248558044434

Stéphane ChazelasはPerlでそのラインを提案しました。

perl -e 'printf "%.17g\n", unpack "f", pack "f", 1.7518248175182483'

浮動小数点数をより高い精度に変換すると、より役に立たない数字に10進表現が与えられるのは、質問が提案する浮動小数点丸め誤差のタイプです。浮動小数点数の内部表現はバイナリなので、内部浮動小数点点の後の数字（バイナリなので、「バイナリ数」）は、2分割（1/2、1/4、1/8など）の累乗を表します。有限の10進数で表すことができる数字は、必ずしも有限の2進数表現を持つ必要はなく、その逆も同様です。これについて詳しくは、次をご覧ください。https://stackoverflow.com/a/588014/60422

単精度は一般的に約7つの小数有効数字に対して機能すると考えられ、これが私たちがここで見ているものです。

この数値によるスケール調整が実際にどのように機能するかを理解するために、関数はスケールに基づいて仮想幅と高さを計算し、整数でget_closest_scale_factor_for_resolutionないmutter場合は計算された幅で始まります。仮想高さを整数にする調整された倍率引数を提供する幅が見つかるまで、または放棄された比率が範囲外または検索しきい値を超える場合。https://gitlab.gnome.org/GNOME/mutter/-/blob/176418d0e7ac6a0418eea46669f33c8e3b03c4bd/src/backends/meta-monitor.c#L1960

知りたいなら開発者が整数ピクセルを得るために倍率を四捨五入することに決めた理由、答えはありませんが、私の推測は以前のバージョンとの互換性です。開発者は整数ピクセルを持つ人々のモニターに精通しているので、既存のソフトウェアはそれのために設計されています。

おすすめ記事