アカウント名:
パスワード:
直接描画してくれるXLib
それなんてSunView [wikipedia.org]? (XLibではないけど)
歴史的には、 SunViewのようにライブラリで直接描画するのは効率が悪い [u-tokyo.ac.jp]、 ということで登場したのが、 Xその他のサーバ・クライアント方式のウィンドウ・システムですね。 Xのサーバ・クライアント方式には、 「ネットワーク・トランスペアレント」という以外にも、理由がありました。
もっとも、現代では共有ライブラリと共有メモリ、 マルチスレッディング等々が普及したこともあり、 当時湯浅先生がおっしゃっていた「最大の欠点」については、 今なら、うまく解決する方法もあるかもしれません。
しかし思い出しましょう。 アプリケーションプログラム間でグラフィックス資源の調停が面倒だった、 SunView(や、その他のライブラリ直接描画方式のシステム)の教訓を。 グラフィックスハードウェアの複雑化した現代では、 その調停は更に困難になってきているかも。 そこをライブラリに作り込んで、 アプリケーションに密結合させる手もなくはないですが、 結局それはXプロトコルと同等以上の複雑さを潜在的に備えることになるでしょう。 さらにセキュリティのことまで考えると、 問題はサーバ・クライアント方式以上に難しくなるでしょう。
なんだかんだで、ハードウェアと各アプリケーション間の調停を行なう、 描画サブシステムのレイヤーを持つのが現実的で、 そうなると、もはやそこをWindowsのように密で複雑なAPIで繋ぐか、 Xプロトコルのような明確に(だが多少行き当たりばったりに)定義された通信で結ぶかの違いはあれど、 結局はある意味でサーバ・クライアント方式と言える形に落ち着くのだと思います。
資源調停以外にも、 クライアントからの要求を再スケジューリングして、 描画ハードウェア資源の利用を最適化するなどというような、 サーバ・クライアント方式でなくては難しい最適化もあり得るので、 一概に「ライブラリ直接描画方式にしちゃえばいい」というのは短絡的に思えます。
なお、別に既存の方式だけがウィンドウシステムのあり方とは思っていないので、 過去をふまえた上で、新しい方式を考案するのは大いにやって欲しいと思います。
最近はあまり面白いウィンドウシステムが出てこないのでつまらないですね。 個人的には、1980年代ごろの、 各社がそれぞれにウィンドウシステムを開発していたころが、 ウィンドウシステムに関しては一番わくわくしていた気がします。 上でも引用したGMWとかNeWSとか出てきたころが、 ウィンドウシステム(の様々な方式)が面白かった最後でしょうか。 逆にPERQ辺りまで遡ると、さすがにリアルタイムでは体験していないですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
どうせなら (スコア:3, すばらしい洞察)
# Xプロトコルが腐れてないと思うのなら、Xの接続方向とか認証とかについて調べてみ？
※元記事は読んでない。
Re:どうせなら (スコア:4, 興味深い)
それなんてSunView [wikipedia.org]? (XLibではないけど)
歴史的には、 SunViewのようにライブラリで直接描画するのは効率が悪い [u-tokyo.ac.jp]、 ということで登場したのが、 Xその他のサーバ・クライアント方式のウィンドウ・システムですね。 Xのサーバ・クライアント方式には、 「ネットワーク・トランスペアレント」という以外にも、理由がありました。
もっとも、現代では共有ライブラリと共有メモリ、 マルチスレッディング等々が普及したこともあり、 当時湯浅先生がおっしゃっていた「最大の欠点」については、 今なら、うまく解決する方法もあるかもしれません。
しかし思い出しましょう。 アプリケーションプログラム間でグラフィックス資源の調停が面倒だった、 SunView(や、その他のライブラリ直接描画方式のシステム)の教訓を。 グラフィックスハードウェアの複雑化した現代では、 その調停は更に困難になってきているかも。 そこをライブラリに作り込んで、 アプリケーションに密結合させる手もなくはないですが、 結局それはXプロトコルと同等以上の複雑さを潜在的に備えることになるでしょう。 さらにセキュリティのことまで考えると、 問題はサーバ・クライアント方式以上に難しくなるでしょう。
なんだかんだで、ハードウェアと各アプリケーション間の調停を行なう、 描画サブシステムのレイヤーを持つのが現実的で、 そうなると、もはやそこをWindowsのように密で複雑なAPIで繋ぐか、 Xプロトコルのような明確に(だが多少行き当たりばったりに)定義された通信で結ぶかの違いはあれど、 結局はある意味でサーバ・クライアント方式と言える形に落ち着くのだと思います。
資源調停以外にも、 クライアントからの要求を再スケジューリングして、 描画ハードウェア資源の利用を最適化するなどというような、 サーバ・クライアント方式でなくては難しい最適化もあり得るので、 一概に「ライブラリ直接描画方式にしちゃえばいい」というのは短絡的に思えます。
なお、別に既存の方式だけがウィンドウシステムのあり方とは思っていないので、 過去をふまえた上で、新しい方式を考案するのは大いにやって欲しいと思います。
最近はあまり面白いウィンドウシステムが出てこないのでつまらないですね。 個人的には、1980年代ごろの、 各社がそれぞれにウィンドウシステムを開発していたころが、 ウィンドウシステムに関しては一番わくわくしていた気がします。 上でも引用したGMWとかNeWSとか出てきたころが、 ウィンドウシステム(の様々な方式)が面白かった最後でしょうか。 逆にPERQ辺りまで遡ると、さすがにリアルタイムでは体験していないですが。
Re:どうせなら (スコア:1, すばらしい洞察)
Re: (スコア:0)
Re:どうせなら (スコア:1)
Waylandがどのような方針なのか分からないけど、
Xlibのインターフェース自体があまり好きにもなれないし、
効率的とも思えないので、gtkとqtが最低限動けばいいという
視点で作った方が良いと思う。
Re:どうせなら (スコア:2, 興味深い)
その作者は Emacs を Windows で動かしたいというのがそもそもの発端だったのだが、結局 BOW と呼べるほどほとんどのAPIを実装する羽目になった。
最低限動かすと言いつつも、必要となる実装範囲は予想以上に広いかも・・・。
本当にネットワークが原因なのか (スコア:0)
Linuxで「UNIXドメインソケット」を何と呼ぶのかは知らんけどさ
Re: (スコア:0)
インターフェースにした方が軽いかなと思った。
Re:どうせなら (スコア:1)
↓のような問題を思いつきました。
● だれがイベントを発行するのか。
たとえば他プロセスのウィンドウが重なっているときの
マウスイベントとか EXPOSE とか。
あと、フォーカスとか。
結局サーバー的な何かが必要になる気がする。
● ウィンドウマネージャの扱いはどうするのか。
既存のXプロトコルと互換性がないと、
ウィンドウマネージャ相当品まで作成するハメになる。
● XLib を使っていない既存のアプリケーションとの協調はどうするのか。
現存するのかどうか知らないけど。
Re: (スコア:0)
論理的なイベントを発生させるサーバ的なものがない場合、
そのあたりはライブラリ側がキーボードとマウスのデバイスから
データを読み込みつつ処理するという事で出来るかもしれません。
> ● ウィンドウマネージャの扱いはどうするのか。
これはどうなんでしょう。Xlibさえ実現できれば出来ちゃうような。
> ● XLib を使っていない既存のアプリケーションとの協調はどうするのか。
CommonLispはXと直接話をするものもあるみたいですね。使っているの見たことないけど。
Re: (スコア:0)
X server でない別の何かをまた作らなくちゃいけなんじゃないの？
Re:どうせなら (スコア:1, フレームのもと)
>>直接描画してくれるXLib
おげ？
あと、これはユーザプロセスの話だから「グラボのドライバを叩く」は「直接」に含まれるからね。
Re: (スコア:0)
最近では「リモートホストのプレゼンテーションをローカルホストに表示する手段」としてはWebが使用されることが多いようです。
Webベースならファイアウォールやプロキシの存在など、現代的なネットワークの諸問題に対応できるメリットはありますが、 これでXプロトコルを完全に置き換えるのは仕様/性能的にまだ無理がありそうです。
(リモートホストのCPU負荷を目視確認するのなら、Webブラウザを上げるよりは、xloadで済ませたい)
ローカルホストへの描画しかしないXlibは、やはり局地戦用兵器だなぁ。
Re:どうせなら (スコア:1)
それ以前に Xlib と呼んでいいでしょうか?
Re:どうせなら (スコア:1)
Re: (スコア:0)
恥知らずなACがあまり調子こくとリアルで痛い目を見て病院で栄養食を食べる事になる
Re: (スコア:0)
本家でも突っ込まれてたけど、
元記事の内容を読む限り、これって、クライアントサイドで動かすものだよね。
それって、Xサーバって呼べるのかな？Xサーバの定義が人によって違うのかもしれないけれど。
Re: (スコア:0)
- Xサーバ：（ユーザから見た）クライアントサイドで動く、描画
- Xクライアント：（ユーザから見た）サーバサイドで動く、計算
だったような気がする。で、彼はXサーバじゃなくクライアントの方に今サーバが受け持ってる描画機能を追加してやるのがいいんじゃないか、って言ってるんだと思った
Re: (スコア:0)
> を追加してやるのがいいんじゃないか、って言ってるんだと思った
Windowsのリモートデスクトップような実装でしょうか？
感覚的なものでしかありませんが、あれは軽くてサクサク動いて好きです。
ああいうのであれば、*NIX系にも是非欲しいですね。
Re: (スコア:0)
その機能をきちんと引き出すドライバが無いと辛いところですが
やっぱりドライバのインタフェースも互換性無いですよね…？
フリー版ドライバだと悲しいぐらい性能が出ないですからね