WaylandとQt
WaylandはLinuxのX11の代替として開発された。Waylandの主な目的は、アプリケーションのコンテンツを共有画面上にまとめて表示する方法と、ユーザーが同じ入力デバイスを共有する複数のアプリケーションと対話する方法を管理することです。
オペレーティング・システムにおけるこの役割は、しばしばディスプレイ・サーバーと呼ばれる。Waylandのディスプレイ・サーバーは、コンポジターや ウィンドウ・マネージャーと呼ばれることもあります。
以下では、WaylandとQtにおけるその役割について簡単に紹介します。Wayland自体の詳細や背景については、公式ドキュメントを参照してください。
ディスプレイ・サーバーとは
ディスプレイサーバとは、画面の領域やその他の共有リソースを管理するオペレーティングシステムの一部です。一般的なデスクトップシステムでは、多くの独立したアプリケーションが同時に動作し、それぞれが画面へのグラフィックスのレンダリングや入力の受信を期待しています。
ディスプレイサーバーは、アプリケーションと、画面や入力デバイスなどの共有リソースをつなぐ役割を果たします。デスクトップ・システム上の典型的なディスプレイ・サーバーは、アプリケーション・コンテンツを、ユーザーによって移動やサイズ変更が可能な、はっきりとした長方形の「ウィンドウ」に配置する。ディスプレイ・サーバーは、アプリケーション・コンテンツが画面上の正しい位置に表示されること、アクティブなウィンドウがキーボードからの入力を受け取ること、重なり合っているウィンドウが正しい順序で描画されることなどを確認します。
他のタイプのシステムでは、ディスプレイ・サーバーはより制限的かもしれない。例えば、スクリーンが自動車の計器パネルやフォークリフトのコントロールパネルである場合、ウィンドウの移動やサイズ変更は望ましくないかもしれない。その代わりに、各アプリケーションは画面のあらかじめ定義された領域に固定され、あらかじめ割り当てられたデバイスから入力を受け取ることができる。
いずれにせよ、孤立した複数のプロセスが同じリソースを奪い合う限り、ディスプレイ・サーバーは有用である。
Waylandの役割
Waylandという名称は、いくつかの関連項目を指すことがある:
- ディスプレイサーバーとそのクライアント間で通信するためのプロトコル群。
- プロトコルを実装するための基礎となる、プロセス間通信のためのC言語で書かれたライブラリ。
- プロトコルを拡張するためのXMLベースの言語と、そのような拡張からC言語でバインディングコードを生成するツール。
Qtは、プロトコルのクライアント側とサーバー側の両方の実装を提供する。
通常のQtアプリケーションは、"wayland "QPAプラグインを選択することで、Waylandディスプレイサーバー上でクライアントとして実行できます(特定のシステムではこれがデフォルトになっています)。さらに、Qt Wayland Compositorモジュールを使ってディスプレイ・サーバー自体を開発することもできます。
Qtには、新しいインターフェイスでWaylandプロトコルを簡単に拡張できる便利な機能もあります。
Waylandとその他のテクノロジー
Linuxデスクトップでは、WaylandはX11と関連する拡張機能に代わるものです。その中核はコンポジティング・ディスプレイ・サーバーであり、"コンポジター "という用語はしばしばWaylandサーバーを表すのに使われる。これは、クライアントがコンテンツをオフスクリーンバッファにレンダリングし、それが後で画面上の他のクライアントと「合成」されることを意味し、ドロップシャドウ、透明度、背景ぼかしなどのウィンドウ効果を可能にする。
オリジナルのX11プロトコルの重要な設計原則の1つは、ディスプレイサーバーを画面と入力デバイスだけのシンターミナル上で実行できることである。クライアントは、より処理能力の高いリモートシステム上で動作し、ネットワーク接続を介してサーバーと通信する。
これとは対照的に、Waylandは、最新のセットアップでは、クライアントとディスプレイ・サーバーは通常、同じハードウェア上で実行されるという観察に基づいて設計されている。分散コンピューティング、リモート・ストレージ、リモート・デスクトップ機能は通常、他のメカニズムで処理されます。これをプロトコルに設計することで、クライアントとサーバー間でグラフィックメモリを共有することが可能になります:コンポジターがクライアントのコンテンツを画面に配置するとき、グラフィックス・メモリのある部分から別の部分にコピーするだけです。
これが最適に機能するためには、グラフィックス・ドライバがWaylandをサポートしている必要があります。このサポートは、EXT_platform_wayland
と呼ばれるEGL
の拡張機能によって提供されます。
注意: Qt Waylandは、EXT_platform_wayland
がサポートされていないシステムでも、XComposite
、またはアプリケーションのコンテンツをCPUの共有メモリにコピーすることで、合成をサポートしています。しかし、最適なパフォーマンスを得るためには、ドライバがサポートされているシステムを推奨します。
X11はコンポジションやダイレクトレンダリングなどの機能をサポートするために拡張されてきましたが、Waylandはこのユースケースを基本として設計されています。また、X11の複雑さとは対照的に、Waylandは小さく拡張可能であることを目指しています。
拡張性と組み込みシステム
Waylandは最小限のコアで拡張が容易なため、組み込みLinuxプラットフォームを構築する際に理想的なツールです。
例えば、デスクトップ・スタイルのウィンドウ・システム機能はコア・プロトコルの一部ではない。その代わり、Waylandには "シェル "と呼ばれるプロトコル拡張の特別なカテゴリがあり、クライアントがサーフェスを管理する方法を提供する。デスクトップスタイルの機能は、XDG Shell
というシェルを通して提供されます。他のタイプのシステムには、より特殊な(そしておそらくより制限の多い)「シェル」を使用することができます。たとえば、車載インフォテインメント・システムを作る場合は、IVI Shell
。
Waylandサーバーは、クライアントが接続すると、サポートしているプロトコル(または「インターフェース」)のリストをブロードキャストし、クライアントは使いたいものにバインドすることができます。これは標準インターフェースのどれでも良いが、新しい拡張も簡単に追加できる。Waylandはプロトコルを定義するためのわかりやすいXMLフォーマットを定義しており、waylandscanner
ツールを使ってこれらのプロトコルからCコードを生成することができます。(Qtでは、さらにC++バインディングコードを生成するqtwaylandscanner
)。
クライアントがインターフェイスにバインドした後、クライアントはサーバーに "リクエスト "を行い、サーバーはクライアントに "イベント "を送ることができる。リクエストとイベント、およびそれらの引数は、プロトコルを記述するXMLファイルで定義される。
ゼロからプラットフォームを構築する場合、サーバーとクライアントの両方のコードを制御する場合、拡張機能を追加することは、オペレーティングシステムの機能を追加する簡単で制御された方法です。
マルチプロセスまたはシングルプロセス
Qt を使ってシンプルな組み込みプラットフォームを構築する場合、UI のすべての部分をシングルプロセスで実行することは、完全に実行可能なオプションです。しかし、システムが複雑になってくると、代わりにマルチプロセスシステムを検討したくなるかもしれません。そこで登場するのがWaylandです。Qtでは、開発プロセスのどの時点でも、シングルプロセスとマルチプロセスの切り替えを選択できます。
マルチプロセスの利点
以下の図は、マルチプロセスとシングルプロセスの違いを示しています。
マルチプロセス・クライアント・アーキテクチャ
シングル・プロセス・クライアント・アーキテクチャ
Qt Wayland Compositorモジュールは、組み込みLinuxのマルチプロセスシステムでディスプレイサーバーとコンポジターを作成するのに理想的です。マルチプロセスの使用には次のような利点があります:
安定性 | |
---|---|
クライアントのハングアップやクラッシュ時の復旧が容易 | 複雑なUIを使用している場合、UIの一部がクラッシュしてもシステム全体には影響しないので、マルチプロセスは便利です。同様に、1つのクライアントがフリーズしても、ディスプレイがフリーズすることはありません。 注意: クライアントにセーフティクリティカルな情報のレンダリングが法律で義務付けられている場合は、Qt Safe Renderer Overview の使用を検討してください。 |
メモリリークの可能性に対する保護 | マルチプロセスシステムでは、あるクライアントがメモリリークを起こして大量のメモリを消費しても、そのクライアントが終了するとそのメモリは回復されます。シングルプロセスとは対照的に、メモリリークはシステム全体が再起動するまで残ります。 |
セキュリティ |
---|
シングル・プロセス・システムでは、すべてのクライアントがお互いのメモリにアクセスできます。例えば、センシティブなデータ転送に対する隔離はありません。コードのすべての行が等しく信頼できるものでなければなりません。マルチプロセス・システムでは、設計上、この隔離が存在する。 |
パフォーマンス |
---|
複数のコアを持つCPUを使用している場合、マルチプロセスシステムは異なるコアに負荷を均等に分散し、CPUをより効率的に使用することができます。 |
相互運用性 |
---|
WaylandやX11を理解できるクライアントであれば、マルチプロセスシステムでQt以外のクライアントとインターフェイスすることができます。例えば、動画に gstreamer を使用する場合や、他の UI ツールキットで構築されたナビゲーションアプリケーションを使用する場合、これらのクライアントを他の Qt ベースのクライアントと一緒に実行することができます。 |
マルチプロセスのトレードオフ
シングルプロセスからマルチプロセスへ移行する場合、以下のトレードオフを意識することが重要です:
ビデオメモリ消費量の増加 |
---|
これは、組み込み機器にとっては制約となり得る。マルチプロセスでは、各クライアントが独自のグラフィックバッファを持つ必要があり、それをコンポジターに送信します。その結果、シングルプロセスの場合と比較して、より多くのビデオメモリを使用することになります。つまり、すべてが一度に描画され、異なる部分を中間バッファに保存する必要がありません。 |
メインメモリ消費量の増加 |
---|
OS レベルでの余分なオーバーヘッドとは別に、複数のクライアントを実行すると、クライアント ごとに一部のパーツを複製する必要があるため、より多くのメインメモリを消費する可能性 があります。例えば、QMLを実行する場合、各クライアントは個別のQMLエンジンを必要とします。その結果、Qt Quick Controlsを使用する1つのクライアントを実行する場合、ロードは1回で済みます。このクライアントを複数のクライアントに分割すると、Qt Quick Controls を複数回ロードすることになり、クライアントを初期化するための起動コストが高くなります。 |
グラフィカル・リソースの繰り返し保存 |
---|
シングルプロセスのシステムでは、同じテクスチャ、背景、アイコンを多くの場所で使用する場合、これらの画像は一度しか保存されません。一方、マルチプロセスシステムでこれらの画像を使用する場合、複数回保存する必要があります。この場合、クライアント間でグラフィカルリソースを共有することが一つの解決策になります。Qtではすでに、Waylandを介さずにプロセス間でメインメモリ上の画像リソースを共有することができます。一方、プロセス間でGPUテクスチャを共有するには、より複雑なソリューションが必要です。Qtでは、このようなソリューションはWayland拡張プロトコルとして、また例えばQQuickImageProvider を使って開発することができます。 |
入力から光子までの待ち時間 |
---|
シングルプロセスのシステムでは、アプリケーションはメインフレームバッファに直接アクセスします。つまり、このようなセットアップでは、入力イベントから画面に反映されるまでのレイテンシを最小化できます。マルチプロセスシステムでは、アプリケーションコンテンツはトリプルバッファリングされ、クライアントがバッファに描画している間に、同時にサーバによって読み込まれることがないようにしなければなりません。これは、マルチプロセスシステムには暗黙の待ち時間が存在することを意味します。 |
X11やカスタムソリューションではなくWaylandを使う理由
前述したように、X11は今日の典型的なシステム・セットアップには最適ではない。X11は非常に大きく複雑で、カスタマイズ性に欠ける。実際、X11でクライアントを流れるように実行し、ティアリングなしで60fpsを達成するのは難しい。対照的に、Waylandは実装が簡単で、パフォーマンスも良く、最新のグラフィックハードウェア上で効率的に動作するために必要なパーツがすべて含まれている。Linuxの組み込みマルチプロセスシステムでは、Waylandが標準となっている。
しかし、古いハードウェアやレガシー・アプリケーションを扱う場合、Waylandは良い選択肢ではないかもしれない。Waylandプロトコルはセキュリティと分離を念頭に設計されており、クライアントが利用できる情報や機能については厳格/保守的です。これはよりクリーンでセキュアなインターフェイスにつながりますが、レガシー・アプリケーションが期待する機能のいくつかは、もはやWaylandでは利用できないかもしれません。
特に、Waylandが最良の選択肢でない可能性がある一般的なユースケースが3つあります:
- ハードウェアやプラットフォームが古く、X11しかサポートしていない。
- Waylandプロトコルにない機能に依存するレガシー・アプリケーションを、セキュリティやシンプルさのためにサポートしなければならない。
- Wayland上で動作しないUIツールキットを使っているレガシー・アプリケーションをサポートしなければならない。場合によっては、これらのアプリケーションをXWayland上で実行することで回避できるかもしれません。
X11が非常に普及していた頃、開発者はX11の問題を回避するために独自のカスタムソリューションを書きました。古いQtのバージョンにはQt Windowing System (QWS)がありました。今日では、これらの使用例のほとんどはWaylandによってカバーされており、カスタムソリューションはますます少なくなってきています。
Qt Waylandが提供するもの
クライアント
Qtクライアントは、Waylandプロジェクトの一部として開発されたリファレンス・コンポジターであるWestonを含む、どのWaylandコンポジターでも実行できます。
どのQtプログラムもWaylandクライアント(マルチプロセスシステムの一部として)またはスタンドアロンクライアント(シングルプロセス)として実行できます。これは起動時に決定され、異なるバックエンドを選択することができます。開発プロセスでは、まずデスクトップ上でクライアントを開発し、後でターゲット・ハードウェア上でテストすることができます。実際のターゲット・ハードウェア上でクライアントを常に実行する必要はありません。
シングルプロセスクライアント開発
Linuxマシンで開発する場合、開発マシンのウィンドウ内でコンポジターを実行することもできます。これにより、ターゲットデバイスに近い環境でクライアントを実行できます。クライアントを再構築しなくても、-platform wayland
を使ってコンポジター内で実行することもできます。-platform xcb
(X11用)を使えば、デスクトップ上でクライアントを実行できます。つまり、コンポジターが使用可能になる前にクライアントの開発を開始することができます。
サーバーの場合
サーバー(コンポジター)はディスプレイに接続し、各クライアントの内容を画面に表示します。コンポジターは入力を処理し、入力イベントを対応するクライアントに送信します。順番に、各クライアントはコンポジターに接続し、ウィンドウの内容を送信します。それはコンポジター次第である:
- コンテンツをどこにどのように表示するか
- どのコンテンツを表示するか
- 異なるクライアントのグラフィックス・バッファをどうするか
つまり、マルチプロセスシステムとは何かを決めるのは、コンポジター次第ということだ。例えば、クライアントは、壁に窓がある3Dシーンの一部であったり、VRシステム上であったり、球体にマッピングされていたり、といった具合だ。
Qt Waylandコンポジターは、独自のコンポジターを構築するためのAPIです。カスタムコンポジターのUIを自由に構築し、様々なクライアントのウィンドウを管理することができます。Qt Wayland CompositorとQt QuickやQMLを組み合わせることで、印象的で想像力豊かなUIを作成することができます。詳しくはQt Wayland Compositorをご覧ください。
Qtはまた、Wayland拡張機能を実装し、QMLやC++から利用するための強力で使いやすいAPIも提供しています。
関連コンテンツ
©2024 The Qt Company Ltd. 本ドキュメントに含まれる文書の著作権は、それぞれの所有者に帰属します。 Qt Wayland Compositor: Creating multi-process user interface © 2024 Qt Company Ltd. 本ドキュメントで提供されるドキュメントは、Free Software Foundation が発行したGNU Free Documentation License version 1.3に基づいてライセンスされています。 Qtおよびそれぞれのロゴは、フィンランドおよびその他の国におけるThe Qt Company Ltd.の 商標です。その他すべての商標は、それぞれの所有者に帰属します。