Wayland vs. X11 の入力遅延議論における具体的な数値
(mort.coffee)- Fedora Workstation 41・GNOME 47 環境で カーソル入力遅延 を 240 FPS スローモーションで撮影し、Wayland と X11 を比較
- マウスが動き始めたフレームからカーソルが新しい位置に表示されたフレームまでを数える方式で、Wayland 16 回と X11 16 回の フレーム遅延 を記録
- GNOME X11 は平均 4 フレーム・16.7ms・2.4 画面リフレッシュ、GNOME Wayland は平均 5.5625 フレーム・23.2ms・3.3 画面リフレッシュと測定
- このシステムでは Wayland が X11 より平均で約 6.5ms 高いカーソル遅延 を示し、差はほぼ画面リフレッシュ 1 回分に近かった
- 結果は GNOME/AMD の組み合わせにおける カーソル遅延の差 のみを示すもので、ゲームや一般的なグラフィックアプリケーションで Wayland の入力遅延がより高いことの証拠ではない
なぜ測定したのか
- ある Linux ユーザーが Wayland の入力遅延への不満を扱った Wayland Cursor Lag: Just give me a break already... をきっかけに、主観的な体感ではなく 具体的な数値 を得るための実験を行った
- Wayland には全体として満足しているものの、X11 より カーソル遅延 があるように感じるという印象が実験の出発点だった
- 既存記事の 90 FPS スマートフォンカメラでは画面リフレッシュ 1 回分の差を判断するのに十分ではないと考え、240 FPS 撮影モードを使用した
測定方法
- スマートフォンのカメラで画面、机、マウスカーソル、マウス、手を一緒に撮影しながら、指でマウスを繰り返し弾いた
- GNOME Wayland セッションで 16 回撮影した後、GNOME X11 セッションにログインして同じ方法で 16 回撮影した
- 撮影した動画は
ffmpeg -i <input file> %04d.jpgコマンドで JPEG フレーム に変換した - フレーム遅延は次の基準で数えた
- マウスが動いているのが見える最初のフレームから計測開始
- カーソルが新しい位置で明確に動いたのが見える最初のフレームまで計測
- 開始フレームと終了フレームの両方を含む
- たとえば 1045 フレームでマウスが動き、1047 フレームでカーソルが動いた場合、3 フレーム遅延として記録する
テスト環境
- 実験に使ったハードウェアとソフトウェアは次のとおり
- ディストリビューション: Fedora Workstation 41
- GNOME バージョン: 47
- CPU: AMD Ryzen 9 5950X
- GPU: AMD Radeon RX 7900XT
- モニター: Gigabyte M32U, 4K IPS, 144.99Hz, DPI スケーリングなし
- マウス: Logitech G502 Lightspeed
- カメラ: iPhone 15 Pro, スローモーション 240 FPS
測定上の制約
- 240 FPS でも 144Hz 画面では 1 回の画面リフレッシュあたりのカメラフレーム数が 2 未満のため、ランダムな揺らぎ が生じる
- ピクセルが即座に切り替わるわけではないため、カーソルが新しい位置にごく薄く見え始める 判断の難しいフレーム が存在する
- カーソルが完全に明るくなっていなくても、新しい位置で明確に見えればカーソルが動いたものとして計算した
- iPhone の映像には一部 重複フレーム が含まれていたが、原因は不明
- 重複フレームは 1 フレーム分の時間が経過したものとみなし、通常のフレームと同様に計算した
- こうした要因は結果に不確実性をもたらすが、Wayland と X11 の両方に同様に作用すると考え、十分なデータがあれば平均化されると見なした
- GNOME 以外の Wayland コンポジタや AMD 以外の GPU ドライバはテストしていないため、他の組み合わせでは結果が異なる可能性がある
測定結果
- GNOME X11 の 16 回の測定値は
5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4フレーム- 平均: 4 フレーム
- 遅延時間: 16.7ms
- 画面リフレッシュ: 2.4 回
- GNOME Wayland の 16 回の測定値は
6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6フレーム- 平均: 5.5625 フレーム
- 遅延時間: 23.2ms
- 画面リフレッシュ: 3.3 回
- このシステムでは Wayland が X11 より平均で約 6.5ms 高いカーソル遅延を示した
- 統計的に有意かどうかを適切に分析できる専門性はないものの、測定値を見る限り明確で一貫した差があるように見える
- 差はほぼ 画面リフレッシュ 1 回分 に近く、これが偶然かどうかは分からない
結論と解釈の範囲
- この実験は、特定のハードウェアにおいて X11 と Wayland の間に 入力遅延の差 があり、一部のユーザーが気づけるほど大きい可能性があることを示している
- 問題の範囲と大きさを明確に把握するには、より多様なハードウェアや画面リフレッシュレートで追加テストが必要
- 差の大きさは、使用しているコンポジタや画面リフレッシュレートなどの要因によって変わる可能性がある
- 追加実験は時間がかかるため、筆者自身が実施する可能性は低い
- このテストは、Wayland が X11 より全般的に入力遅延が高いことを示すものではない
- 特にゲームで Wayland の入力遅延がより高いことの証拠ではない
- 追加遅延は カーソル専用 である可能性がある
- カーソルは一般的なグラフィックアプリケーションとは大きく異なる形で処理されていると理解している
- Wayland がゲームで X11 より高い入力遅延を示すかどうかは別途テストが必要
1件のコメント
Hacker News の意見
素晴らしいアプローチ。人々はもっと実験で確認できることを、あまりにも頻繁に推測で済ませているように思う。科学的方法を学んでからは、いつも「実験を設計してみよう」という方向に引かれるようになった
Wayland でなぜ追加の遅延が生じるのかは分からないが、X11 が最初に出てきた頃のコンピューターコミュニティにいた立場から言うと、初期の頃から画面遅延への不満は絶えなかった。カーソルの反応でも xterm のスクロールでも同じだった
「ワークステーション」が登場した頃には、マウス専用の表示ハードウェアを別に持つものもあり、フレーム内にマウスをレンダリングする遅延を減らすための仕組みだった。有名な XOR 特許もあった: https://patents.google.com/patent/US4197590
こうした不満のおかげで、キーボード/マウス入力から画面反映までのコードパスは、常に「より速く、より低遅延に」する方法が検討されてきた。Wayland は X11 に比べれば相対的に「新しい」ので、それほど長く検証されてきたわけではないが、改善されていくことを期待している
プレーンは、画面の残りを再描画しなくても更新したり位置を変えたりできる。通常の画面画像は基本プレーンにあり、カーソル移動は新しいプレーン位置をコミットすることに近い
ここで使われた Wayland サーバーである GNOME Mutter が追加する入力遅延は、おそらく入力サンプリングとコミットタイミング戦略の問題である可能性が高い。サーバーごとに戦略や優先順位が異なり、長所短所が生じる
Wayland はプロトコルなので、通常のカーソル位置指定の過程には関与しない。したがってこの問題は完全にディスプレイサーバー内部の実装と最適化の領域だ。プロトコルレベルでは、クライアントにカーソル画像を設定させ、クライアントへカーソル位置を知らせる程度のことしか起きない
記憶では、Xorg に glamour が登場してから状況が悪くなり始めた。カーソルのレンダリング経路がシグナルハンドラー内で実行しても安全ではなくなり、OpenGL ベースなら当然そうならざるを得ず、遅延がさらに悪化した
昔は Linux マシンがスラッシング中でもマウスポインターは反応し続け、カーネルが止まったのかどうかを判断する信頼できる指標だった。ポインターの反応があまりに早い段階でなくなるなら、IDE/PATA ホストで hdparm により unmask irq を有効にすべき場合だった。XFree86 で反応しないポインターは、何かがおかしいか設定が間違っていることを示す非常に有用なサインだったので、あの頃が懐かしい
無料ソフトウェアに文句を言っているのは分かっているが、これはあまりにも長い間、より悪い方向へ強制移行され続けている。Wayland の導入は、あらゆる入力と表示要件においてほぼ普遍的に優れているという前提の上で行われるべきだった
Intel、AMD、Nvidia、Arm のメーカーは、使い物になるデスクトップ Linux のためにコンソーシアムとして総力を挙げるべきだ。政府も同じだ。安全な Linux デスクトップは実際に可能であり、CPU や 3D 機能、高度なベクター/コンピューターハードウェアを示す最速の道でもあるからだ
Wayland は、Windows がひどいタイル UI で自滅しようとしていた時期、Apple が一般的な x86 向け macOS を出せば得られたはずの追加時価総額を頑なに拒んでいた時期に登場し、Linux デスクトップの遅れをさらに広げた格好だ
工夫が必要なのはウィンドウやアイコンをドラッグするときで、このときスワップチェーンの遅延が見え始める。一部のウィンドウコンポジターは高リフレッシュレートのおかげで遅延が目立ちにくいと見て、もはや気にしていない。例えば macOS がそうで、Windows はドラッグ中にソフトウェアマウスカーソルへ切り替えているようだ
フルスクリーンアプリはコンポジターを通るか、迂回する高速経路を通るべきだ
このようなフレーム単位の分析に ffmpeg を使う人なら、
ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.pngで動画の各フレームの表示時刻を取得できる。単にフレームをダンプしてタイムスタンプを計算するより正確だWeb ブラウザーでも、動画を再生しながら
requestVideoFrameCallback()を使えば同様のことができる。ただしコンピューターが全フレームを十分速くデコードできない場合は、.playbackRateを下げる必要があるかもしれない144Hz 画面で Wayland が X11 より平均で約 6.5ms 遅く、その差がほぼ 1 回の画面更新に等しいという点は偶然ではないかもしれない。遅延がほぼ 1/144 秒なら、一般的な 60Hz モニターでは 1/60 秒になる可能性もある。訓練なしに意識して気づくのは難しいが、多くの人は説明できなくても「感じる」ことができる
もちろん多くのユーザーにとっては 125Hz のマウスポーリングレートも撹乱要因になるが、この場合は 1KHz マウスを使っていた
7ms の差は悪くないが、16.6ms の差はかなり大きくなり始める。個人的には、コンピューターは1.6 フレームの遅延を目標に努力すべきだと思う。ランダム位相の半フレーム、1 フレーム、そしてわずかな処理時間といった程度だ
結果はコンポジター、GPU、設定によって変わるはず。X11 では、Linux デスクトップシステムが使う X サーバー実装が事実上 1 つしかないため、こうした差は小さい
いまだに多くのコンポジター/GPU の組み合わせで ハードウェアカーソルプレーンを得られない問題があるかもしれず、そうであればこのような遅延差は十分に起こり得る
今日知ったのだが、Wayland はもう 16年にもなる。数年後には、Wayland が登場した時点での X と同じ年齢になるはずなのに、いまだに平凡、あるいは X 未満だと見なされているようだ
$very_specific_featureをサポートしていない」か、「自分のグラフィックカードメーカーのプロプライエタリドライバーが Wayland で十分にテストされていなくて悲しい」という意味であることが多いそうした不満の約 99.999% は、1) 自分では作業せず、2) 作業する関心や能力もなく、3) Wayland と X の開発者の多くが同じ人たちで、彼らがもはや X11 の作業をしたがっていないことを理解していない、または認めていない人たちから出ている
この論争に特別な利害関係はないが、他人が無料で提供してくれたソフトウェアを使いながら Wayland に文句を言うのを見るのにはうんざりしている。Wayland への不満がそれほど多いなら、今ごろ団結して X を保守・改善し、不満や理論が正しければ Wayland を置き去りにすることもできたはずだ
奇妙なことに、X はオープンソースでいくらでもフォークでき、XFree86 から X.org が生まれた事例もあるのに、支持者たちはほこりをかぶらせたままで、保守には何もしない
「Wayland は X ほど良くないので、誰でも使える現代化された X フォークを作った」という成果物が出てきたら、かなり興味深く見るだろう
つまり Wayland は、Wayland が登場した当時の X の年齢の約 66% にすぎず、同じ年齢になるには現在の Wayland の寿命からさらに 50% が必要になる
今 Plasma 6 で Wayland を使っていて十分うまく動いているが、特別な要件はないので、たとえばスクリーンリーダーがどれほど良く動くかは分からない
その時点では、ブラウザのフロントエンドスタックがデスクトップを完全に飲み込んでいると予想している。そもそも Linux に新しいデスクトップアプリがたくさん出ていたわけでもない
動いている解決策を「より現代的で、保守しやすく、将来に備えられる」という理由で書き直そうとする試みは、たいていそうならないので驚きではない。多くの場合、より遅くなり、遅延が増え、より高速なハードウェアが支えているだけで、ソフトウェアが速くなったわけではない
20年ごとに新しい世代が、前の世代が苦労して作った抽象化に甘えきって、さらに弱くなっていく感じがする。ソフトウェア開発者が 3世代ほど経つと、残ったのはライブラリ/フレームワークの呼び出し手だけで、性能と最適化をきちんと理解している人はほとんどいない
Wayland には X11 に比べてまだ足りない機能はあるが、他の利点のためならその程度は妥協するつもりだ
複数の Wayland コンポジターには、キーボード、マウス、その他の入力デバイスで大きな問題がある。Wayland の仕様と参照実装がそれらをサポートしないことにしたためだ。そのため各 Wayland コンポジターがそれぞれ別の解決策を選んでいる
一般的な選択肢は libei と libinput だが、「高度な」マウス/キーボード入力はそもそもサポートしない場合も多い。weston がその例だ。特定の Linux ソフトウェアが特定の Wayland 環境で動くかどうかはまったく分からず、断片化が深刻だ
X では、実際にすべてを実装する強力な X11 参照があるので、ある場所で動けば別の場所でも動くと確信できる
12年も経ったのに、視覚障害者向けのスクリーンリーダーをサポートする Wayland コンポジターは 1 つもない。おもちゃレベルだ
だからゲームにも良くなく、プロ向けのグラフィック作業にも良くなく、視力の良くない人にも良くない。結局、作った人たちと少しでも違うユーザーには概して良くないということだ
それでも運が良ければ、私が一度も体感したことのない画面のティアリングは減らせたのかもしれない
ここから生まれた素晴らしい成果の 1 つは、人々がこのエコシステムの上にアクセシビリティのワークフローを追加していることだ。ある人は音声操作で、タイル型ウィンドウマネージャーを通じてデスクトップ全体を操作している: https://youtu.be/fiPJLmhnnXM
GPU に大きな負荷がかかっているとき、たとえば Stable Diffusion の推論のような作業をしているときに、大きな遅延スパイクが発生する。X11 と A/B テストをしたわけではないが、以前はこういう記憶がない。
1 フレーム分だけ追加で遅延するのも好ましくはないが、時々跳ねる 遅延スパイクが本当にいら立たしい。
カーソル入力の遅延は、アプリケーションや OS への満足度をじわじわ損なう邪魔者だ。
IDE のテキストカーソル遅延？ 受け入れられない。
シェルのテキストカーソル遅延？ 受け入れられない。
GUI のマウスカーソル遅延？ 受け入れられない。
すべて即アウトの条件だ。
40 年以上前、ほとんど無限に非力なハードウェアで動いていた System 1 でさえ、カーソルの応答性を最優先にしてすべての競合を上回っていた。現在の OS と UI の基盤は 100% 別物になったが、その優先順位は今も保たれている。
最近、KDE/Plasma 6 の X11 と NVidia の組み合わせで、ひどいマウスのもたつきを経験した。特にブラウザのタブ上で遅さがひどいことに気づいた。
同じ問題を抱えている人のために書いておくと、解決策は OpenGL flipping をオフにすることだった。OpenGL flipping が何をしているのかはまったく知らないが、nvidia-settings と
/etc/X11/xorg.confでオフにしたら問題は解決した。なぜそうなるのか、あるいはなぜこれがデフォルトでないのか、誰か説明してくれるとうれしい。
素晴らしい作業だ。モニターを非常に低いリフレッシュレート、たとえば 30Hz にして実験を繰り返してみる価値がありそうだ。
Wayland が常に X11 より 1 フレーム遅いなら、はるかに観察しやすくなるはずだ。
少し別の個人的な不満がある。初めて Linux を使い始めたころ、デスクトップはソフトウェア合成だった。おそらく CPU が RAM に UI を描画してから GPU のフレームバッファへブリットするような形で、ずっと以前からそうしてきた方式だったのだと思う。
コンポジタ、X11 composite まで含めて、さらに GPU レンダラが流行するにつれて遅延はひどくなり、文字どおり数百 ms レベルになった。DOS ゲームで育った身としては、当時はこんな問題はなかったので奇妙だった。
時間が経つにつれて改善はされたが、私たちが CPU レンダリングの黄金時代に戻ってきたのかはよく分からない。