アカウント名:
パスワード:
Xの限界は10年近く前から言われてきているので今更な感じもあるのですが, remoteへの表示なのかlocalなのか切り分けて考えないと論点がぼやけますよ.
タイトな表示をさせようとしたら Xの場合localでやってもきついのに Ether越しの例を出しても…… 最近のXも頑張ってはいると思うんですけどね.
VNCや「リモートデスクトップ接続」などのアプローチでいいじゃん。
VNCの方が遅くないですか? VNCって全画面分飛ばすんですよね? それならapplicationごとにやり取りでき
サーバクライアントモデルがある限り、それが足枷となってローカルの描画はどんなに頑張ってもダメダメ。
ここについては全く同意見です. それを解決するためにXも拡張していっているんですけどね. まぁまだまだ満足できるレベルではないですが. この辺の問題はX上で大きな動画などを表示しようとすると 顕著に出ますからね.
VNCは画面更新された部分だけを転送します。
だからでかいWindowを動かしたりすると たまらないくらい遅いわけ
今までの議論を眺めていたあんまり詳しくないACです。
XShmでは、ビデオカードのVRAMも共有できる仕組みがあるんでしょうか。 クライアントがメインメモリに描画しなければならないのでは、リアルタイム系のアプリは致命的に遅くなると思うんですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
あなたは二番目ね (スコア:2, 興味深い)
「あれ、随分昔に Y Window system って無かったっけか?」
と不思議に思ってました。で、さっきやっと発見。
The Y Window System [hungry.com]
1998年から更新が無いようです。
「Xにとって代わるもの」の候補は他にもいろいろ名乗りを上げています
が、上の初代 Y Windows System のように最早忘れ去られているものも
ある状態。この Y はどうですかね?
ところで、Yの
Re:あなたは二番目ね (スコア:1, 興味深い)
クライアントで分断されてるデザインはさすがに時代遅れと思いますね。
full colorの画面を表示するためだけに何度無駄なコピーが発生することやら。
それに1画面3MBの転送を100BaseTで送ったら、3fpsしか出ないよ。
そろそろ、クライアントロジックと表示が分断さ
Re:あなたは二番目ね (スコア:2, すばらしい洞察)
Xの限界は10年近く前から言われてきているので今更な感じもあるのですが, remoteへの表示なのかlocalなのか切り分けて考えないと論点がぼやけますよ.
タイトな表示をさせようとしたら Xの場合localでやってもきついのに Ether越しの例を出しても……
最近のXも頑張ってはいると思うんですけどね.
VNCの方が遅くないですか?
VNCって全画面分飛ばすんですよね? それならapplicationごとにやり取りでき
Re:あなたは二番目ね (スコア:2, 参考になる)
> 最近のXも頑張ってはいると思うんですけどね.
ウィンドウシステムのレンダリングに、サーバクライアントモデルが意味が無い、という話です。
サーバクライアントモデルがある限り、それが足枷となってローカルの描画はどんなに頑張ってもダメダメ。
もう何年も言われていることですが、端末のGPUの描画性能が年々上がっていくにつれ、
乖離が激しくなっています。どんどん要求は高まっているのです。
> VNCの方が遅くないですか?
> VNCって全画面分飛ばすん
Re:あなたは二番目ね (スコア:1)
ここについては全く同意見です.
それを解決するためにXも拡張していっているんですけどね. まぁまだまだ満足できるレベルではないですが.
この辺の問題はX上で大きな動画などを表示しようとすると 顕著に出ますからね.
だからでかいWindowを動かしたりすると たまらないくらい遅いわけ
Re:あなたは二番目ね (スコア:0)
> 満足できるレベルではないですが. この辺の問題はX上で大きな動画などを
> 表示しようとすると 顕著に出ますからね.
そうですね。たとえばXにFlashやSVGレンダリングを追加してもいいのでしょ
うが、結局blitがダメダメな時点で、しょせんは付け焼刃に過ぎないと思いま
す。
>>>> # OpenGLやSDL使えって?ゲームならいいだろうけど…
>>> SDLはともかくOpenGL使ってXの描画が早くな
Xの仕組み、わかっていますか? (スコア:2, 参考になる)
Xの仕組みと一般なアプリケーションやライブラリの実装について解説します。
Xには、同じ画像データでもWindowやPixmapなどXサーバ(XFree86等)側に確保される
リソースと、XImageのようにクライアント(xtermやemacs)側に確保されるリソースが
あります。
アイコンやjpegファイルのデータ等基本的に変更されないデータに対してはPixmapと
して処理し、ゲーム等プログラム側でデータを変更する場合には扱いやすいXImageを
使用します。
例えば、jpegファイルを表示するプログラムがあったと
Re:Xの仕組み、わかっていますか? (スコア:0)
勘違いかと思いますが、Xはexposeされた部分を転送するのに対し、VNC は更
新された部分を転送します。もちろん、たいていの場合はXの方が速いですよ。
> ローカルでは画像データをXサーバとXクライアントの共有メモリに置き、サー
> バとクライア
Re:Xの仕組み、わかっていますか? (スコア:0)
> 新された部分を転送します。もちろん、たいていの場合はXの方が速いですよ。
意味不明。どう意味ですか?
XクライアントがExpose Eventをどう処理するかはアプリケーションの自由なんですが。
また、XクライアントがまじめにExpose eventを処理しているという前提で、VNCの方が
速くなる具体例を出してください。
> shmも含めて不可避なコピー回数が共通の問題点という認識です。
これもよくわかりません。
XではXクライアントとXサーバ間のデータ転送には手間がかかります。#501298で
Re:Xの仕組み、わかっていますか? (スコア:0)
どうぞ。VNC Documentation [realvnc.com]
> XクライアントがまじめにExpose eventを処理しているという前提で、VNCの
> 方が 速くなる具体例を出してください。
議論の中では「VNCでも代替になる」というのが主旨で、これは枝葉末節に過
ぎないことを最初にお断りしておきます。
たとえば、SVGで白地に簡単な図形をレンダリングした結果を複数個、連続領
域に転送する場合、VNCは結果をまとめて圧縮をかけて転送します(先ほどのURL
にプロトコルの仕様書があります)。この場合はVNCが勝つかもしれません。と
はいえ、適切に最適化されたXクライアントにVNCが勝つ
Re:Xの仕組み、わかっていますか? (スコア:0)
まず、Xクライアントは表示用のWindowを作り、ゲーム画面に対応するデータ領域をX
サーバとの共有メモリとして確保します。この領域はXクライアントからは普通にメモリ
として直接アクセスでき、Xサーバからもメモリとして直接アクセスできます。
Xクライアントは対応するデータ領域に直接ゲーム画面を書き込み、この領域を更新する
ようにXサーバに通知します。すると、Xサーバはこの更新領域に直接アクセスできるので、
BitBlt等を使って、ビデオカードに転送し、表示します。
したがって、
>> XではXクライアントとXサーバ
Re:Xの仕組み、わかっていますか? (スコア:0)
今までの議論を眺めていたあんまり詳しくないACです。
XShmでは、ビデオカードのVRAMも共有できる仕組みがあるんでしょうか。 クライアントがメインメモリに描画しなければならないのでは、リアルタイム系のアプリは致命的に遅くなると思うんですが。
Re:Xの仕組み、わかっていますか? (スコア:1)
DirectXではVRAMに直接描画するよりメインメモリに描画してからblitするほうが平均的に速い。
直接描画したいというからには標準のblit等ではできない特殊処理とかで何度もread/writeすると思いますが、
外部バスの(たぶん)非キャッシュ領域にせこせこアクセスするより、メイ
Re:Xの仕組み、わかっていますか? (スコア:0)
そうでない場合は、あらかじめテクスチャをVRAM上に溜め込んでおいて、
描画処理はほとんどGPU中だけの変換&合成で終わらない?
ところでこれ最近のXで出来るの?>詳しい人
Re:Xの仕組み、わかっていますか? (スコア:0)
サーフィスを確保してくれるのか知らないが。
それに、VRAMでなくメインメモリにテクスチャを置いても、GPUはメインメモリからVRAMに
blitできるから、GPUだけで処理できると思われ。
メインメモリ→VRAMのblitとVRAM→VRAMのblitでどのくらい速度が違うかは知らない。
Re:Xの仕組み、わかっていますか? (スコア:0)
API見たけど、その際に回転も拡大もα以外の合成もしてくれないみたい。しょぼん。
> VRAMでなくメインメモリにテクスチャを置いても、GPUはメインメモリからVRAMに
> blitできるから、GPUだけで処理できると思われ。
GPUがマスタのDMAでも、CPUはその間メモリ見にいけないから、やっぱりしょぼん。
> メインメモリ→VRAMのblitとVRAM→VRAMのblitでどのくらい速度が違うかは知らない。
Re:Xの仕組み、わかっていますか? (スコア:1)
単純な2Dのbitblt/mask程度だったら
あらかじめビットマップをXのPixmap(WindowsでいうところのGDIのDDB)でシステムに溜め込んでおいて(VRAMに乗るかメモリに乗るかはシステム依存)GPUで終わると思うし、
回転拡大縮小αとかするのであれば、3Dのハードとドライバがあれば、(X上の)OpenGLあるいはDirect3Dで
>あらかじめテクスチャをVRAM上に溜め込んでおいて、
>描画処理はほとんどGPU中だけの変換&合成で終わらない?
終わるでしょう。