Wayland Overview

個人的に初日のセッションの目玉はこれ。X Window System(以下 X) を中心に数々の設計・実装を行ってきた Keith PackardWayland と Qt について話すという、Qt に興味が無くても Unix 系のデスクトップに興味のある人にはとても面白いセッションだと思います。Qt Developer Days 2012 Europe にはなかった、North America だけのセッションです。

まずは Wayland の概要の説明から。ここに限らず全体的に X との比較が入ってくるので、X に関する知識、とくに伝統的な Xlib プログラミングと近年のプログラミング手法に関する知識がある方が理解は深まる内容でした。欲を言えば、その辺りの時代による変化の説明が欲しかったところでしょうか。

Wayland は Qt5 で正式サポートされますが、その他にも Clutter, EFL, SDL, Gtk+ 3 などのツールキットで対応が行われて/進められています。その大きな特徴の一つが Xlib にあるような描画系の API が定義されていないことでしょう。今時の X プログラミングと同様にサーバーとは描画用のバッファのやりとりを行い、フォントも含め各種の描画はバッファに対して直接クライアントが(多くの場合 OpenGL を利用して)行います。X プロトコルが CPU もメモリも高価で貧弱だった時代に合わせて設計されたものならば、いかにも最近の事情を考慮した設計になっているとも言えます。全体的に処理の流れを単純化してバッファのコピー回数を減らすなど高速化のためのアーキテクチャになっている反面、ウィンドウデコレーションをクライアント側で描画するなどクライアントのコーディング負荷も大きくなっていると感じました。こういったことから、Wayland を直接利用するアプリの作成はあまり想定されていなく、ツールキット経由での利用が想定されているように思われます。

また、サーバー側でも、描画を担当するサーバーとウィンドウマネージャ(Compositor?)などが分離している X に対して、Wayland ではサーバーがウィンドウマネージャとしても動作するという違いがあります。

その Wayland も今年にようやく 1.0.0 がリリースされ API が安定しました。Qt では Qt5 で正式に Wayland に対応することもあって、その機能がすべて Wayland 上でも動くことが必要な要件となるということです。組み込みでの利用が先行すると思われる Wayland ですが、シングルプロセスを想定している EGLFS QPA プラグインに対して、マルチプロセスで動作するのが特徴となります。ただし、QtWayland はまだ Wayland 1.0 への対応が不十分なこともあり、(Wayland 側から見て)問題が若干あるようです。

Qt5 の QtWayland モジュールでは Wayland クライアントとして動作する QPA プラグインの他に、Compositor として動作する QtCompositor があります。ここでは、Wayland のリファレンス実装である Weston と QtCompositor との比較も行われました。QtCompositor は独自の Compositor の作成を容易にするものの、Qt 以外の Wayland クライアントとの接続が考慮されていないなどの問題があるそうです。手軽に Compositor が作れることは評価されているものの、実用には最適化もされている Weston の利用が推奨されていました。

Qt4 以前の組み込み Linux での主流であった QWS との比較に関しては、QWS はアクセラレーションの利用が難しいことを述べ、OpenGL の利用が一般的になってきた今では Wayland の方が速度的に有利だと言うことでした。

最後に X 上で Wayland を動かして、Qt/X ではなく、Qt/Wayland でアプリを動かして欲しいと要望してセッションの締めとなりました。その際に、OpenGL と QPainter を混ぜるようなコードはパフォーマンスを低下させるのでやめて欲しいと言うことでした。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください