Xを造り直すなら
A. そのアイデアは間違っている
X11を置き換えるというのは非常にpainfulなのに意味がない。X11には誰も使っていない機能、例えばフォントサーバ*1等も残ってはいるが、それらは単に使わなければ良い。
X11を実現しているメッセージ層、つまり一定のパケットフォーマットに従ったメッセージやドメインソケットは、それ自身では重要なパフォーマンス問題は引き起こさない。
ドメインソケットはUNIXのセマンティクスにおいてX11のようなことを実現する手段としては(ほぼ)最高の手段で、もし、それよりも良い手段を用意するならば、それはOSを造り直すのと同じような手間になる。もちろん、machのようなメッセージシステムは検討に値するが、Linuxにはそれが無いのだから採用する意味はない。
GUIのためにOSからやり直すのは多くの支持を集めるようなやり方ではない。個々のアプリケーションに特化したGUIフレームワークそのものを抽象化して、別途X11の互換レイヤを持つことの方が圧倒的に簡単で有用だろう。ユニバーサルなGUIプロトコルは(だれもそれにアプリケーションを書こうとしないから)もう必要とされていない。PCにおいてはWindows(と、MacOS)の支配力は未だ圧倒的で、組み込み用途であればその機器のアプリケーションは基本的に単一であるため。
B. 言語環境から考え直す
UIはC言語で書けない。これはシェーダがC言語で書けないのと根は同じ問題で、C言語はインタラクションを表現するために適したプログラミング言語ではない。型安全でないから入力の検査は毎回行う必要があるし、継続が無いからイベントループを書かないといけない。
そう考えたときのX11の仕事は今の仕事よりもずっと少なくなる。描画データを生成するプロセスと、実際に描画するプロセスを分離し、後者をサーバ側にリンクして使えばプロセス間のデータ転送は少なくできる。
C. 良い3Dハードウェアの抽象化レイヤとする
X上のOpenGLのパフォーマンスはDirectXには勝てない。OpenGLとX11の機能性を両立させることは本来困難で、VM支援機能のないプラットフォームで実現されるVMのような物といえる。
この問題は今まさに取り組まれている。
展望
OS側のI/Oスケジューリングとの連携は避けられない変化に思える。Linux上のCellプロセッサはデバイスに見えるし、デバイスを連携させたスケジューリングには一定の需要が有る。
そこにビデオカード上の演算リソースを載せるためには、実行コードを抽象化する必要がある。OpenCLのような共通のプログラミング言語は多分状況を改善するが、ビデオカード上にあるエントロピデコーダや他のシステムを抽象化できない。
これらの変化のためには大きな資本が必要で、そのためには大きな市場規模が必要になる。人間に対するリアルタイムなディスプレイを最終目的地とするのではなく、より大きな演算タスクのために良いスケジューリングや抽象化を提供し、それを流用すべきだろう。
CUDAは(記憶が正しければ)GLXに依存しているが、これはあまり望ましくないように思える。
それらとは異なる(安上がりな)もう一つの方向性こそが、Waylandのように『実用上』十分なXサーバを必要最低限のハードウェアサポートで作ることだろう。
