実際、これはちょっと悪質で無知な投稿だね。もしくは、無知な人たちの主張を否定するための間違い（知っててやったのかどうかは不明）かもしれない。空間をしっかり理解してる人は、X11で物理ディスプレイサイズを取得して、それをレンダリングするピクセル数にマッピングするのが不可能だなんて言わないよ。これは数十年前から可能だったし、完全に簡単ではないけど、良いUIスケーリングをする上での難しい部分ではない。良いUIスケーリングには、動的なスケーリング変更のためのインフラ、同じシーン内でのディスプレイごとの異なるスケールファクター、どんなスケールファクターでもシャープなラインを保証するための仕組みが必要なんだ。これらの問題は、X11でも追加の努力で解決できたはずで、一部は部分的な解決策として実現されてた。コミュニティは、Waylandスタックにエネルギーを注ぐことを選んだんだよ。

ツールキット（Motif、Tk、Gtk、Qtなど）は fractional scaling に対応できなかったから、Waylandが簡単な道を選んでたら、すべてのアプリが壊れちゃうところだったよ。

"2倍スケールで描いてから縮小"っていうやり方を広めたのはOSXだよね。元々OS Xは、2倍スケールで描いてから縮小することなく描画するのがデフォルトだったんだ。ハードウェアが2倍スケールに必要なピクセル数を持つように設計されてたからね。例えば、2012年の初代Retina MacBook Proは、前の非Retina MacBook Proの幅と高さがどちらも2倍だった。結局、ハードウェアのコストが高くなりすぎて、これが難しくなったんだと思う。例えば、27インチの5K LCDパネルと27インチの4KパネルのSKUはどれだけ違うのか？でもAppleが整数スケーリングファクターを採用して縮小することを決める前に、もっと伝統的なアプローチを試してたんだ。TigerやLeopardなどの初期のOS Xリリースでそれが見られるよ。問題は、Apple自身が自社アプリに実装するのにかなりの労力がかかって、サードパーティアプリの採用が低くなるのを知ってたことだね。このLeopardのHiDPIレンダリングの例を見てみて：https://cdn.arstechnica.net/wp-content/uploads/archive/revie... これはAppleのTextEditアプリで、バグがあったんだ。スケーリングファクターを非整数に変更するためのいいUIもあったよ：https://superuser.com/a/13675

OS Xのグラフィックスって、ずっとDisplay Postscript/PDF技術に基づいてるんじゃなかったっけ？なんで2倍でレンダリングしてダウンサンプリングしなきゃいけないの？ベクターベースのプリミティブをネイティブ解像度でそのままレンダリングすればいいのに。

OSXで流行った「2倍スケールで描いてから縮小する」ダンスをやってるけど、Linuxはそれをやってない。 > Waylandが最初からこうしなかったのは変だね。最初は整数スケールファクター用にやってたし、後からは分数スケールファクターにも対応したけど、一部のWaylandベースの環境は早くからそれを実装してたよ。

Waylandは2022年からX11スタイルの分数スケーリングをサポートしてるよ: https://wayland.app/protocols/fractional-scale-v1 。QtとGTKの両方がWaylandでの分数スケーリングをサポートしてる。

最初の画像が十分大きければ、ダウンスケーリングによるぼやけはそれほど悪くないよ。例えば、1.3ピクセル対10.1ピクセルみたいな感じ。

Windowsはずっとこれを試してたけど、実際にちゃんと動くアプリはなかったよ。Excelがデバイスに依存しないピクセルでまともに表示できるようにするのに、何年もかけたけど、やっぱり人は生のピクセルで考えちゃうのが難しいんだよね。

だから、ぼやけたスーパーレゾリューションに基づくダウンサンプリングのミームがどこから来たのか理解できない。もしそうなら、スーパーレゾリューションアンチエイリアシング[1]は何なの？ダウンサンプリングされた解像度よりも高い解像度でレンダリングされた画像は、通常、ダウンサンプリングされた解像度でレンダリングされた画像よりもシャープだよ。これは、高周波成分をよりよく保持するから。ダウンサンプリングに基づく他のアンチエイリアシング技術もいくつかあって、すべて信号対雑音比を向上させる。これってUIにも効くんじゃないの？ほとんどがベクターグラフィックスだし。ビットマップアイコンは更新が必要だけど、他のUI（テキスト）はシャープであるべきだよね。1ピクセルの線（完全に水平または垂直）について言及する人がいるのは知ってる。その後、1.25倍とかに掛け算して、「ああ、見て、0.25ピクセルは嘘だ、だから分数スケーリングはフェイクだ」って言う（スウェイのドキュメントは今でもこれを言及してる）。これは、非常にニッチなメンタルエクササイズ以外では実際には成立しないように思える。十分に高い解像度では、私たちが話しているディスプレイのケースでは、1ピクセルの線が本当に欲しいの？ほとんど見えないよ。今、Linuxでこの問題に直面してる。さらに、線がドラッグ可能な場合、クリックゾーンも小さくなりすぎる。物理的な寸法を持つ何かが欲しいだろうし、それはおそらく複数のピクセルを必要とするだろう。その時点で、見えないアンチエイリアスが必要になるだろう。さらに、1ピクセルの線は、プログラムが指定した色である必要はない。私の画面上の完全に水平で垂直な線のほとんどは灰色がかってる。AAのアーティファクトがあれば、色が少し変わるけど、実質的な影響はないと思う。そうだとしたら、スーパーレゾリューションはかなりうまく機能するはずだ。じゃあ、本当に欲しいのは次のようなものだね：1. ほとんどの「デスクトップ」アプリケーションに対するスーパーレゾリューションスケーリング。2. 一部のフルスクリーンアプリケーション（ゲーム、動画再生）にはネイティブ解像度を与え、動画再生のようなアプリには画面上の矩形のネイティブ解像度を与える。これにより、これらのアプリケーションで情報損失を引き起こす可能性のある高解像度でレンダリングしてからダウンサンプリングするのを避けられる。3. これをセッション単位ではなく、アプリケーション単位で行う。LinuxのDEはこれを実装していない。KDEはセッション単位を実装しているけど、柔軟性が足りない。起動時に各アプリケーションごとに設定する必要がある。 [1]: https://en.wikipedia.org/wiki/Supersampling

Linuxを使ってるけど、コンポジタのコードを書いたり、仕組みを詳しく知らない自分からすると、WaylandはX11よりも fractional scaling（小数スケーリング）に対応してるのが全然良いね。少なくとも、X11で1.5倍のスケールを設定するのは全くできなかった。いつもアドバイスは「使ってるアプリごとにフォントサイズを大きくすればいい」だったし。Waylandで fractional scalingを使うと、XWaylandのアプリはいつもすごくぼやけて見えるけど、Waylandネイティブのアプリはめっちゃ綺麗に見えるよ。