- 従来のWayland環境は、コンポジタとウィンドウマネージャが1つのプログラムとして結合された構造だったが、river 0.4.0ではこれを別プロセスに分離した
- 新しいriver-window-management-v1プロトコルは、ウィンドウマネージャにウィンドウ配置やキーバインドなどのポリシー全般の権限を与えつつ、フレーム完全性(frame perfection) と性能を維持する
- この構造は入力遅延(latency) なしで動作し、複雑なタイルレイアウトでも原子的な状態更新によって整ったレンダリングを保証する
- 分離された構造により、ウィンドウマネージャは独立して開発・再起動可能であり、高水準言語でも実装しやすい
- このアプローチはWaylandエコシステムにおけるウィンドウマネージャの多様性拡大を促進し、riverはすでに15個以上の互換マネージャをサポートしている
Waylandの従来構造とriverの分離アプローチ
- 従来のWaylandコンポジタは、ディスプレイサーバ、コンポジタ、ウィンドウマネージャの3つの役割を1つのプロセスに統合していた
- ディスプレイサーバは入力イベントをルーティングし、カーネルに表示バッファを渡す
- コンポジタは複数ウィンドウのバッファを合成して最終画面を生成する
- ウィンドウマネージャはウィンドウ配置やキーバインドなどのユーザーポリシーを担当する
- X11の構造ではディスプレイサーバが別プロセスとして存在するため、不要な往復通信と遅延が発生した
- Waylandはこれを解決するためにサーバとコンポジタを統合したが、ウィンドウマネージャまで結合することは必須ではない
- riverはこの結合を解き、ウィンドウマネージャを別プログラムとして分離した
river-window-management-v1プロトコルの設計原則
- ウィンドウマネージャが最大限の制御権を持ちながらもWaylandの利点を維持できるよう設計されている
- 毎フレームや入力イベントごとに往復通信を必要とせず、入力遅延がない
- フレーム完全性(frame perfection) を維持: ウィンドウが新しく開いたりサイズ変更されたりするときに、隙間や重なりのない画面更新を保証する
- すべてのウィンドウが新しいバッファを提出するまでレンダリングを遅らせるが、一定時間を超えた場合はタイムアウトで処理する
- よく実装されたアプリケーションほど、完全なフレーム同期が可能になる
状態マシンベースのウィンドウ管理構造
- プロトコルは状態をウィンドウ管理状態とレンダリング状態に分ける
- ウィンドウ管理状態: ウィンドウサイズ、フルスクリーンかどうか、キーボードフォーカス、キーバインドなど
- レンダリング状態: ウィンドウ位置、順序、装飾、クロップなど
- 変更事項は原子的更新(manage/render sequence) としてまとめて処理される
- コンポジタがシーケンスを開始し、状態変化がないときはウィンドウマネージャが待機状態に保たれる
- この構造は既存のriver-classicやswayなどにも内在していた概念を明示的に定式化したものだ
分離構造の利点
- ウィンドウマネージャ開発者はコンポジタ全体を実装する必要なく、ポリシーに集中できる
- デバッグと再起動が容易で、ウィンドウマネージャのクラッシュがセッション終了につながらない
- ガベージコレクション言語で書いても性能低下がなく、フレーム遅延なしで動作する
- すでに15個以上のriver互換ウィンドウマネージャが存在し、X11並みの多様性拡大が期待される
限界と今後の計画
- 現在のプロトコルは2Dデスクトップ環境のみをサポートし、VRなどには未対応
- 複雑な視覚効果（例: 揺れるウィンドウ）は対象外だが、単純なアニメーションは可能
- 今後カスタムシェーダ対応を検討中だが、短期的な計画ではない
- river 0.4.0は日常利用に十分であり、1.0.0への移行前にUX改善が予定されている
- 開発継続のため、liberapay、GitHub Sponsors、Ko-fiを通じた支援を呼びかけている
例とギャラリー
- riverで動作するさまざまなウィンドウマネージャの例を紹介
- Canoe: クラシックなスタッキング型ウィンドウマネージャ
- reka: Emacsベースのウィンドウマネージャ
- tarazed: 集中型デスクトップ環境
- rhine: 再帰的・モジュール型のウィンドウ管理とアニメーションをサポート
- このほかにも多数のriver互換ウィンドウマネージャが存在する
1件のコメント
Hacker Newsの意見
コメント欄での Wayland（プロトコル）に対する不満は理解しづらいと感じる
wlroots のようなライブラリがすでに重い部分を処理しており、今では river がより高水準の抽象化を提供している
Wayland プロジェクトがこうした抽象化をもっと早く提供できた可能性はあるが、誰にでもできたことだと思う
結局、私たちはこうした進歩を無料で得ているのだから、誰かが代わりにやってくれないと不満を言う必要はないと思う
アクセシビリティの問題もセキュリティリスクと見なされ、設計が難しくなったが、今やAgentic AIの時代に入ってきていて、これは興味深い論点になりそうだ
Pipewire が Wayland の取りこぼしを埋めつつあるが、依然としてユーザーフレンドリーな設計が不足しているという認識がある
それでも Wayland は一歩か二歩後退しても、全体としては二歩前進していると思う
「自分たちのやり方が嫌なら出ていけ」というような対応が多く、外部からの要望に柔軟ではない
無料で提供されている点は良いが、Xorg が終了し代替もない状況で半ば強制的に押し進めるのは問題だと思う
今回のプロジェクトを見て、初めて Wayland は時間の無駄ではないと感じた
ディスプレイサーバーがわざわざウィンドウ管理まで複雑に担う必要はないと思う
もともと Wayland がウィンドウマネージャとコンポジタを統合した理由は、単に抵抗の少ない道だったのだろう
ただしリモートアクセス機能は依然として問題だ。X11 ではうまく動いていたものが Wayland ではバグが多かった
Wayland はこれを統合して解決したが、別の副作用も生んだ
API の境界がうまく設計されていて、コード共有がしやすい
90度回転バグが compositor 側の問題なのか wlroots 側の問題なのか気になる
Wayland のさまざまな設計上の欠陥の一つが、ようやく修正され始めたのだと思う
共通プロトコルが定着し、ウィンドウマネージャが X11 並みに成熟するまでには、さらに 15 年はかかりそうだ
そして結局また誰かが「もっと良いものを作る」と言って Wayland を捨て、新しく始めるのだろう
UEFI の問題に悩まされた末、結局Samsung DEXに移った
限界は技術的というより政治的な問題だと思う
Linux ユーザー歴 25 年だが、5 年前に Wayland に移行して以来、画面のティアリングの問題なしで満足している
開発者の立場では仕事が増えるだろうが、ユーザーとしては明らかな改善だ
昔の CDE の機能を懐かしむ人たちのように、自分もずっとこの話をし続けることになるのだろうかと思う
River は分離前から素晴らしかった。今後の発展が楽しみだ
一時的に Niri に移ったが、いつかまた戻るつもりだ
Xmonad ユーザーなら River がいちばん合うと思う
River では新しいウィンドウが現在選択中のウィンドウの上に挿入されるのか気になる
分離後はウィンドウマネージャ側のプロジェクト名が何になるのかも知りたい
結局、私たちは X11 の機能を一つずつ再発明しているだけだ
いつか Wayland のウィンドウが自分の位置を分かるようになるのかもしれない
しばらくは待つことになりそうだ
デスクトップは Android、ChromeOS、あるいは Windows/macOS 上の VM が占めることになりそうだ
自分は完全にカスタマイズしたRiver ウィンドウマネージャを使っている
Hyprland では基本的に BSP タイリングしかできず不便だったが、River では望む通りの均等タイル配置が可能だ
この分離は自分のワークフローに大きな変化をもたらした
自分も以前は i3 ユーザーだったが、hy3 のおかげで Hyprland を使えるようになった
自分の設定は dotfiles にまとめてある
Wayland の中核設計の一つはウィンドウマネージャとコンポジタの統合だったと理解している
なぜそう設計したのか気になる
Wayland はこれを同期的に処理して視覚的な不一致をなくした
今回のプロトコルは、その性能上の利点を維持しつつ、グラフィックスサーバーとウィンドウマネージャを分離しようとする試みだ
Wayland ではプラグイン型ウィンドウマネージャを簡単に差し替えられない点が、X11 と比べた最大の損失だと思う
こうした問題を解決しようとしている人たちは本当に貴重な存在だ
River や Wayback のようなレイヤーがその役割を果たしてくれることを望む
自分にも実験的なデスクトップのアイデアはあるが、高速な反復が可能な X11 で始めるしかない
Wayland には依然として設計上の弱点がある
標準で特定の構造を強制する必要はない
15 年間 i3 を使っているが、こういうプロジェクトが出るたびになぜ Wayland が必要なのか疑問に思う
X11 には欠点があっても、やりたいことのほとんどは実現できる
Wayland はいつも摩擦が多そうに見える
ノート PC ユーザーとして大きな利点であり、VRR や HDR のサポートも X.org よりはるかに容易だ
ディスプレイごとの DPI 調整、画面ティアリング防止、そしてアプリによる無断スクリーン録画の遮断が標準で解決されている
もう Xorg.conf をいじらなくてよくなり、生活の質が上がった
今でもモニターごとに異なるスケール比を使っている
ウィンドウが非アクティブでも入力を受け取る機能が必要なのだが、マウス移動だけが例外的に動く
結局 Window Event に変えたが、やはり不便だ