開発者向けの主要プラットフォームであり続けるために
LinuxのGUIアプリへの対応が必要?
Microsoftは、WSL2(Windows Subsystem for Linux 2)でLinux GUIアプリケーションに対応することを計画している。以下の動画は昨年9月に開催されたXDC 2020のセッションのものだ。
この改良はかなり大きなものと言える。以前紹介したWSL2のGPUコンピューティングへの対応も(「Windows 10のWSL2からGPUが使えるようになった」)、WSL2内でGPUによる描画(ただし表示ではない)の前段階の一部である。ちょっと大きめの話でもあるので、今回は前後編に分けて紹介していく予定だ。
ではなぜ、WSL2でLinux GUIアプリケーションに対応しなければならないのだろうか。それはおそらく、ChromebookやPC上の仮想マシン環境(Hyper-Vを含む)などとの関係からだと思われる。
まず仮想環境では、仮想ディスプレイデバイスを介して、Linuxのデスクトップを表示可能になっている。このためにはOSの「準仮想化」が必要で、Hyper-VやViraualBoxにはグラフィックス表示が可能なLinuxディストリビューションがある。
さらにChromebookでは、仮想マシン内でLinuxを動作させ、Linux GUIアプリケーションのウィンドウをChrome OSのデスクトップに表示・利用できるようになった。このことでAndroidのアプリ開発はChromebookだけで完結する。GoogleのGUI開発環境であるAndroid StudioがChromebookで動作するわけだ。それ以外にも、EclipseなどLinux上のGUIを持つ開発環境がある。
Microsoftとしては、Windowsが開発者向けの主要なプラットフォームであることを維持したい。そういう背景もあり、WSL2でLinux GUIアプリケーションを動作させることにしたのだと考えられる。
もう1つの理由として考えられるのが、Microsoftが進める.NET Frameworkのマルチプラットフォーム化だ。Linuxでも.NET Frameworkのアプリケーションを動作させることを考えると、Windowsと同じGPUコンピューティング(DirectML)やDirectXグラフィックスを利用するアプリケーションが動作することが望ましい。
物理デバイスの制御に関しては、Linuxの流儀に従うとしても、上位のAPIレベルでは、なんとか互換性を取りたいところ。そのためには、LinuxでもWindowsと同等のグラフィックス、GPU利用APIを動かしたい。そういう方向性でプレビューが開始されたのが、WSL2でGPUコンピューティングを可能にする機能というわけだ。
この際に導入されたのが、以下の図のようなDirectX GraphicsをWSL2内で動作させる仕組みだ。ただし、現時点でも、MESAなどの対応は完了しておらず、CUDAなどからGPUが利用できるに留まっている。
DirectX Graphicsでは、対応GUIアプリケーションは、DirectX GraphicsやOpenGLなどを使って自身のメモリ領域(バッファ)に描画指示や描画リソース(ビットマップなど)を置いて、GPUに処理させる。GPUコンピューティングではほぼ同じ仕組みだ。このとき、DirectXのユーザーモードドライバーを利用する。WPFなどの抽象度の高いグラフィックス描画でも下の部分は同じ。最終的にアプリのプロセスごとにウィンドウ内の描画を作る。
Windows 10ではDesktop Window Manager(DWM)が合成してデスクトップに表示する。ここにもGPUが使われている。こうした構造をCompositorあるいはComposit形式という。
そもそもCompositorを使ってデスクトップを「合成」するというのは2000年以降に普及し始めた。かつては、ウィンドウマネージャーがアプリケーションに通知(隠れていたウィンドウの一部が表示されたなどのイベント)してウィンドウを直接描画させていたが、アプリケーションにより、描画が遅い、あるいは描画をきちんとやらないといったことで、デスクトップ全体の応答速度が犠牲になったり、不完全なウィンドウのままになることがあった。
ウィンドウ内の描画が「完了」したかどうかは、アプリケーションにしかわからないためだ。そしてウィンドウマネージャー側は、描画の終了を待たねばならず、他のウィンドウを更新できなくなる。これが全体の足を引っ張ることがあった。
そこで、ほかに影響が出ないようにアプリケーションプロセスには自身のメモリなどに置いたバッファに描画をさせ、ウィンドウマネージャーは、描画が終了したものを合成して表示するようになった。こうすることでアプリケーション側がどう振る舞おうとも、自分の中で完結している処理なので、デスクトップの表示に影響を与えない。GPUを利用した描画は、アプリケーション側でユーザーモードドライバーなどを使って自分のところで処理するようになった。
アプリケーションの描画が問題でデスクトップ全体の速度が落ちてしまう問題は、Windowsにもあり、Windows VistaでDWMという形でCompositorが搭載された。Windows Vista以後、ウィンドウタイトルに「応答なし」と表示されるのをよく見かけるようになったのはこうした事情による。Windows Vistaからは、一定時間内(5秒)にDWMからのイベントに応答しないウィンドウの代わりに絵を描いただけのGhost Windowを表示し、そのタイトルバーに「応答なし」と表示しているのだ。
この連載の記事
-
第459回
PC
WSL 2.4.4ではtar形式でのディストリビューションが配布でき、企業での利用が容易になってきた -
第458回
PC
Windows上でhostsファイルを活用する -
第457回
PC
IPv6アドレスは先頭を見ればどんな種類かわかる -
第456回
PC
あらためてIPv6基本のキ -
第455回
PC
Windowsで現在どのネットワークアダプタがインターネット接続に使われているかを調べる方法 -
第454回
PC
Windows 11 24H2では「デバイスの暗号化」の条件が変わり、より多くのPCでドライブが暗号化される -
第453回
PC
Windows 11 24H2の配布開始後もすぐにはやってこない Windows UpdateとSafeguard Holds -
第452回
PC
Windows 11 Ver.24H2が登場 Copilot+ PCとそうでないPCで実質Windowsが2つに分かれる -
第451回
PC
新しいWindowsサンドボックスではコマンドラインからの制御が可能に -
第450回
PC
ユニコードで文字数を数える方法 -
第449回
PC
WSLはプレビュー版でGUIでの設定が加わった! リリース2.3.xの新機能を見る - この連載の一覧へ