「Linux向けの新Xサーバー開発プロジェクト「Wayland」」記事へのコメント

どうせなら

[tarosuke (2403)]

腐れたXプロトコルなんて捨てて、Xサーバじゃなくて直接描画してくれるXLibにすればよかったのに...。
# Xプロトコルが腐れてないと思うのなら、Xの接続方向とか認証とかについて調べてみ？
※元記事は読んでない。

Re:どうせなら

[Anonymous Coward]

直接描画してくれるXLib

それなんてSunView [wikipedia.org]? (XLibではないけど)

歴史的には、 SunViewのようにライブラリで直接描画するのは効率が悪い [u-tokyo.ac.jp]、 ということで登場したのが、 Xその他のサーバ・クライアント方式のウィンドウ・システムですね。 Xのサーバ・クライアント方式には、 「ネットワーク・トランスペアレント」という以外にも、理由がありました。

もっとも、現代では共有ライブラリと共有メモリ、 マルチスレッディング等々が普及したこともあり、 当時湯浅先生がおっしゃっていた「最大の欠点」については、 今なら、うまく解決する方法もあるかもしれません。

しかし思い出しましょう。 アプリケーションプログラム間でグラフィックス資源の調停が面倒だった、 SunView(や、その他のライブラリ直接描画方式のシステム)の教訓を。 グラフィックスハードウェアの複雑化した現代では、 その調停は更に困難になってきているかも。 そこをライブラリに作り込んで、 アプリケーションに密結合させる手もなくはないですが、 結局それはXプロトコルと同等以上の複雑さを潜在的に備えることになるでしょう。 さらにセキュリティのことまで考えると、 問題はサーバ・クライアント方式以上に難しくなるでしょう。

なんだかんだで、ハードウェアと各アプリケーション間の調停を行なう、 描画サブシステムのレイヤーを持つのが現実的で、 そうなると、もはやそこをWindowsのように密で複雑なAPIで繋ぐか、 Xプロトコルのような明確に(だが多少行き当たりばったりに)定義された通信で結ぶかの違いはあれど、 結局はある意味でサーバ・クライアント方式と言える形に落ち着くのだと思います。

資源調停以外にも、 クライアントからの要求を再スケジューリングして、 描画ハードウェア資源の利用を最適化するなどというような、 サーバ・クライアント方式でなくては難しい最適化もあり得るので、 一概に「ライブラリ直接描画方式にしちゃえばいい」というのは短絡的に思えます。

なお、別に既存の方式だけがウィンドウシステムのあり方とは思っていないので、 過去をふまえた上で、新しい方式を考案するのは大いにやって欲しいと思います。

最近はあまり面白いウィンドウシステムが出てこないのでつまらないですね。 個人的には、1980年代ごろの、 各社がそれぞれにウィンドウシステムを開発していたころが、 ウィンドウシステムに関しては一番わくわくしていた気がします。 上でも引用したGMWとかNeWSとか出てきたころが、 ウィンドウシステム(の様々な方式)が面白かった最後でしょうか。 逆にPERQ辺りまで遡ると、さすがにリアルタイムでは体験していないですが。

Re:どうせなら

[Anonymous Coward]

まあ実物なしで机上の神学論争はいくらでもできますが、X Window Systemを脱却したUNIX [apple.com]ならすでに実在しますね。既存のXクライアントを動かすためにXサーバも使えるようにはなっていますが。

Re:

[Anonymous Coward]

昔々あるところに次とかいう計算機があっての、それを作った某は、Xは脳死していると言ったとか。当時儂はMITに居たもので気分を害したが、今では禿げしく同意している。