Flutterをデスクトップの「中」に埋めた新Waylandコンポジター

Arch Linux向けに、FlutterエンジンをWaylandコンポジターの内部に直接組み込んだ「Denial」がパブリックアルファとして公開された。

FlutterはUIフレームワークのはずだった

Googleが開発したFlutterは、モバイルアプリやWebアプリの画面を描くためのフレームワークとして知られている。通常のFlutterアプリケーションは、既存のウィンドウシステムからウィンドウを受け取り、その中で描画する。コンポジターの上で動くクライアントの1つにすぎない。

Denialはその関係を逆転させた。FlutterをWaylandクライアントとして動かすのではなく、Flutterエンジンそのものをコンポジターの基盤層に埋め込んでいる。デスクトップの描画基盤がFlutterであり、シェル、ウィンドウの配置、アニメーション、設定画面のすべてがFlutterのシーンとして構成される。

その上で動くWaylandアプリケーション（ChromiumやFirefox、Blenderなど）のバッファは、EGL_EXT_image_dma_buf_importを使ってGPUテクスチャとして直接Flutterシーンに取り込まれる。CPUによるピクセルコピーは発生しない。Flutterはそのシーンを画面全体のGBMバッファに直接レンダリングし、DRM/KMSで表示する。中間レンダーターゲットもなければ、2段階目の合成パスもない。

RustとFlutterの役割分担

内部構造は2層に分かれている。

低レベル側はRustで書かれ、WaylandコンポジターライブラリのSmithayを基盤にしている。Waylandプロトコルの状態管理、クライアントバッファ、入力デバイス、フォーカスとグラブ、出力構成、DRM/KMS表示、ネイティブリソースの寿命管理。低レベルの仕事はすべてRustが受け持つ。

高レベル側はFlutterとDartだ。デスクトップ上に見えるもの（シェルのレイアウト、ウィンドウの配置と移動、システムUI、設定画面、通知、アニメーション）はDartで記述されたシェルとして動く。シェルはAOTコンパイルされ、コンポジタープロセスの内部で実行される。

この2つの層はバージョン管理された境界で分離されている。現在のシェルはdart_shell/ディレクトリに格納され、AOTライブラリ・アセット・ICUデータ・エンジン世代が1つの実行時バンドルとして読み込まれる。将来的には、互換性のある別のFlutterシェルをこのバンドル単位で差し替えられる。ネイティブコンポジターを入れ替えずに、デスクトップの見た目と振る舞いだけを丸ごと変えられる構造だ。

開発者が使っている、という事実

アルファ版ではあるが、公開リポジトリには開発者本人が常用環境として使っているという記述がある。

対応状況として挙げられているのは、Chromium、Firefox、Blender、Discordなどのネイティブアプリケーション、Xwayland経由のX11アプリ、SteamとProton経由のゲーム（アークナイツ：エンドフィールド、鳴潮、NTE: Neverness to Everness、ファイナルファンタジーXIV）。マルチモニター構成、通知、アプリ単位の音量調整、画面ロックとDPMS（ディスプレイの省電力管理）、OBSでの画面共有にも対応し、署名付きArch LinuxパッケージがCI/CDで配布されている。

Flutter開発のワークフローもそのまま維持されている。オプションの開発パッケージを導入すると、Flutter Inspector、DevTools、ホットリロードがライブデスクトップ上で機能する。Dartシェルのコードを書き換えれば、コンポジターやアプリケーションを再起動することなく、パネルやウィジェットが目の前で変化する。

さらにFlutter EngineとSkiaのビルドをカスタマイズし、外部テクスチャのダメージ追跡、フレームスケジューリングの特殊化、ホットパス上のヒープ割り当て除去といったコンポジター固有の最適化を施している。

OpenAI Codexとの協業

技術的なアーキテクチャとは別に、このプロジェクトにはもう1つの側面がある。

GitHubのREADMEには、DenialがDoctor Logixというハンドル名の開発者によって構想・設計・指揮・テストされ、OpenAI Codexとの継続的な対話の中で実装されたと明記されている。初期実装はCodexとの協業で生成され、手動で書かれたものではないという。

Authorship is more than typing source code.
（著作者であるとは、ソースコードを打つこと以上の意味を持つ）

READMEの末尾にこの一文がある。設計判断・技術的方向性・品質評価は人間が行い、コードの探索・提案・生成・修正をCodexが担った。結果はすべて実機でテストされ、設計意図に合わない出力はやり直された。

先月公開されたStarlingもClaudeとの協業で構築されたLinuxデスクトップ環境だった。

Starlingは独自のWaylandコンポジターとX11サーバーを持ち、FlutterのDart層をSwiftに移植するアプローチを採った。DenialはFlutterをそのまま使い、コンポジターの内側に埋め込む道を選んだ。

方向は異なるが、「1人の設計者がAIと組んでデスクトップ環境を構築する」という共通点がある。1本のOSSデスクトップを作り上げるのに必要な人数が、変わり始めている。

なぜDenialという名前なのか

Origin does not have to dictate purpose.

「出自が目的を決めるわけではない」。公式サイトに掲げられたこの一文は、Flutterの転用だけを指しているわけではない。

「Denial」という英単語の中には「Denia」が含まれている。ゲーム『鳴潮』（Wuthering Waves）のキャラクター「ダーニャ」（英名：Denia）への言及だと、READMEは説明している。ダーニャは他者から目的を与えられた存在だったが、自ら心を育て、何になるかを自分で選ぶに至ったキャラクターだ。

アプリケーションUIのために作られたフレームワークが、デスクトップ描画の基盤になる。その設計思想と物語を、名前に重ねている。

現状はArch Linux x86-64専用のアルファ版で、公開時点のGitHubにはコミットが2つ、スターが5つ。成熟したプロジェクトとはまだ言えない。だがコンポジターが常用環境として機能し、重量級ゲームが動いている以上、技術的に成立することは見せている。

ツールの可能性は、作った側ではなく使う側が切り開く。Denialはそれを、コードで証明しようとしている。

関連記事

• Xfce Waylandコンポジタ「xfwl4」初版が公開
• Rust製X11サーバーyserver 1.4。SteamとChromeがGPU加速に対応
• AIが作ったLinuxデスクトップ。今度は本物だった
• RustとAIで1からX11サーバーを書き直す。yserverが問いかけるもの
• Discord、Linux対応を強化 称賛が届かなかった理由