この記事は Qt Blog の "Multi-process Lighthouse"を翻訳したものです。
執筆: Jørgen Lind 2011年3月18日
Lighthouse は QtGui から特定のウィンドウシステムへの依存を解消するプロジェクトです。この場合、QtGui はどのウィンドウシステム上で動作しているかは知らずに、使用されるプラグインに対して単に命令を送っているだけになります。
Lighthouse では(QWS が提供してきたような)サーバー／クライアントが動作するマルチプロセスには対応していませんでした。もちろん、この機能を独自に開発すること自体は可能で、Marius が DevDays のセッションのために開発した ウィンドウシステム では独自に設計したプロトコルで動作していました。しかし、私と Paul はこのような独自プロトコルを Qt として正式に採用しメンテナンスすることには反対でした。なぜなら、マルチプロセスのウィンドウシステムプロトコルの作成の難しさを QWS の経験から学んだからです。QWS は正式なプロトコルなしに実装されてきました。このため QWS のサーバーとクライアントは互いに強く依存しあう結果になりました。
我々はこのようなプロトコルがどこかで策定され、Lighthouse がそれに対応するという状況を望んでいました。そして、新しく誕生した Wayland プロジェクトがまさにこれにあたるものでした！Wayland はマルチプロセスのウィンドウシステムの仕様です。Wayland のクライアントとサーバーのライブラリは、クライアント／サーバー間の通信を行いますが、描画内容や描画の合成処理には関知しません。Wayland のサーバーは「Compositor」と呼ばれる画面を管理するウィンドウマネージャーです。Wayland の詳細はプロジェクトのホームページ http://wayland.freedesktop.org/ をご覧ください。
ここ数ヶ月の間、私は Paul と Samuel と共に Wayland と格闘していました。かなり早い段階で、１つの Compositor によって全てのウィンドウが管理されることはないということが分かりました。小さなスクリーンの組み込み機器での要求はデスクトップ Linux とは異なりますが、できる限りのことを Qt の Compositor という形で行いたいと思いました。これが、我々が Qt-Compositor というリサーチプロジェクトを開始した理由です。このプロジェクトのゴールは、みなさんが独自の Wayland Compositor を実装する際にベースとなるレイヤーとして使用可能な機能を提供することです。
右図ではこのアーキテクチャを表しています。スクリーン上で動作する Lighthouse プラグイン(左側、上から２番目のブロック)は、グラフィックスカードの設定などを行うでしょう。ディスプレイの情報は Qt と Lighthouse の API を通して、Qt-Compositor と カスタム Compositor で利用可能になります。
Qt-Compositor は Wayland Compositor に必要な全ての通信を抽象化します。このため、カスタム Compositor を実装する人の主な作業は各ウィンドウの内容が最終的にどう描画されるかを決めることになります。
クライアント側には、ディスプレイの情報はこのプロトコルに沿って送られてきます。これらは通常の Qt の API を通して全てのクライアントから利用可能です。
素晴らしいことに、これを利用した Compositor では Qt が提供する全ての描画技術を利用できるのです！
- QPainter を使用し QWidget での合成 〜 「当然です！どうぞご自由にお試しください :)」
- QGraphicsView での合成 〜 「もちろん！スクロールエリア上でやってることだよ :)」
- 現在開発中の Qt Quick SceneGraph プロジェクトでの合成 〜 「うん、それは面白いよね！」
数日前に Samuel が最高に素晴らしい Compositor のサンプルを qml scene graph を使用して作りました。全ての機能には対応していませんが、qml を使用した Qt-Compositor の作成方法や、ウィンドウに対するシェーダーを簡単に書く方法など、いくつもの素晴らしい機能が見られます。
