アカウント名:
パスワード:
Xの限界は10年近く前から言われてきているので今更な感じもあるのですが, remoteへの表示なのかlocalなのか切り分けて考えないと論点がぼやけますよ.
タイトな表示をさせようとしたら Xの場合localでやってもきついのに Ether越しの例を出しても…… 最近のXも頑張ってはいると思うんですけどね.
VNCや「リモートデスクトップ接続」などのアプローチでいいじゃん。
VNCの方が遅くないですか? VNCって全画面分飛ばすんですよね? それならapplicationごとにやり取りでき
サーバクライアントモデルがある限り、それが足枷となってローカルの描画はどんなに頑張ってもダメダメ。
ここについては全く同意見です. それを解決するためにXも拡張していっているんですけどね. まぁまだまだ満足できるレベルではないですが. この辺の問題はX上で大きな動画などを表示しようとすると 顕著に出ますからね.
VNCは画面更新された部分だけを転送します。
だからでかいWindowを動かしたりすると たまらないくらい遅いわけ
今までの議論を眺めていたあんまり詳しくないACです。
XShmでは、ビデオカードのVRAMも共有できる仕組みがあるんでしょうか。 クライアントがメインメモリに描画しなければならないのでは、リアルタイム系のアプリは致命的に遅くなると思うんですが。
それにXのDGA拡張で問題が解決するなら、Xに問題があるわけではないと言うことになります。
あげ足取りのようで申し訳ないのですが, 『Xに問題があるからDGA拡張が出来た』とも言えますよね. で, 現状のDGA拡張は(慣れの問題かもしれませんが)同じような機能を持つSGIのGL拡張よりも使いづらいですし, 『まだまだ』なレベルだと思っています. なので現状でXに速度的な問題があるというのは間違いでないと思いますが.
個人的には次世代のXでもこのYでもここら辺の問題をクリアしてくれるのであれば歓迎ですね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
あなたは二番目ね (スコア: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の描画が早くなるんですか?
>
> もうしわけないですが 詳細を教えてもらえると嬉しかったりします.
ここでの焦点は「サーバークライアントモデルだとblitが遅いからダメダメ」
のつもりですので、その点ではSDLもOpenGLもblitの高速化を果たすという意
義があります。画面デバイスを占有するのが欠点ですが。
Xの仕組み、わかっていますか? (スコア:2, 参考になる)
Xの仕組みと一般なアプリケーションやライブラリの実装について解説します。
Xには、同じ画像データでもWindowやPixmapなどXサーバ(XFree86等)側に確保される
リソースと、XImageのようにクライアント(xtermやemacs)側に確保されるリソースが
あります。
アイコンやjpegファイルのデータ等基本的に変更されないデータに対してはPixmapと
して処理し、ゲーム等プログラム側でデータを変更する場合には扱いやすいXImageを
使用します。
例えば、jpegファイルを表示するプログラムがあったとすると、まず、表示するための
Windowを作り、jpegファイルを展開したPixmapを作り、PixmapからWindowsに転送する
ようにXサーバに指示します。
そのあと、Windowが隠れまた前面に出された場合、再度表示され部分の情報がXサーバ
から通知されるので(Expose)、それにしたがって、アプリケーションはPixmapから
Windowsに隠れていた部分を転送するようにXサーバに指示します。
この動作で帯域を喰うのは、最初のjpegファイルからPixmapを作成する部分だけです。
あとは、アプリケーションがXサーバに必要な処理をするよう命令するだけで、Xサーバ
内部で動作が完結するようになっています。
さらに、Xサーバはハードウェアのアクセラレーション機能(BitBlt)を利用して高速に
描画するようになっています。
VNCやRDP(Windowsのリモートデスクトップ)ではある程度キャッシュすることはできても
ここまで最適化することはできません。
gtk+やqt等を使えばXクライアントは自動的にこういう動作をします。
したがって、
> VNCは画面更新された部分だけを転送します。
> ですから、X11よりも描画が速くなることもあります。
これは誤りです。
Xも更新された部分だけ処理するし、多くの場合Xサーバ側にデータを置いているので、
更新部分のデータを転送せずに済み、より効率的になっています。
ただ、実際のライブラリでは、基本的に、更新された部分単位で細かく処理せず、露出
されるWidget単位で描画処理をする場合が多いので、VNCの方が速くなる場合がないわけ
ではありません。
また、XImageに関しても、ローカルでは画像データをXサーバとXクライアントの共有
メモリに置き、サーバとクライアント間でデータの転送を行わなくて済むXShm拡張と
いうのがあります(Pixmapにも同じ拡張があるが、あまり使われていないはず)。
この拡張を利用し、リモートではXImage、ローカルではXShm拡張を使うよう動作する
ライブラリがあり、この代表がSDLです。
したがって、SDLへの言及は意味不明です。SDLはただのライブラリであり、それ以上
のものではありません。
さらに、root特権が必要なので実際に使っているアプリケーションは少ないですが、
VRAM等ビデオカードに直接アクセスできるDGA拡張というのもあります。
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)
# 外野から見ていた利用者の立場
Re:Xの仕組み、わかっていますか? (スコア:0)
って話です。XとVNCの比較ではないです。そもそもXは駄目って話。
Re:Xの仕組み、わかっていますか? (スコア:0)
> 域に転送する場合、VNCは結果をまとめて圧縮をかけて転送します
レンダリングしたデータをどうXサーバに転送するかはクライアントが決めることができる
ので、当然Xでもまとめて転送できます。また、Xには圧縮して転送する拡張もあります。
VNCでは更新されている部分をVNCが探して転送しないといけません。
そのため、Xクライアントが最適化されているなら、更新部分を探さなくて済む分、Xの方が
圧倒的に速くなります。
したがって、Xの方が仕組み上優れているということになります。
Re:Xの仕組み、わかっていますか? (スコア:0)
まず、Xクライアントは表示用のWindowを作り、ゲーム画面に対応するデータ領域をX
サーバとの共有メモリとして確保します。この領域はXクライアントからは普通にメモリ
として直接アクセスでき、Xサーバからもメモリとして直接アクセスできます。
Xクライアントは対応するデータ領域に直接ゲーム画面を書き込み、この領域を更新する
ようにXサーバに通知します。すると、Xサーバはこの更新領域に直接アクセスできるので、
BitBlt等を使って、ビデオカードに転送し、表示します。
したがって、
>> XではXクライアントとXサーバ
Re:Xの仕組み、わかっていますか? (スコア:0)
実際にやったことないし、現実にそういうことをするライブラリがあるかどうかわかり
ませんが、Pixmapにも同じ拡張があります。
jpegファイルを表示するプログラムでは、表示用のWindowを作り、jpegファイルを展開
するPixmapをXサーバとの共有メモリとして作ります。この領域は、クライアントからも、
Re:Xの仕組み、わかっていますか? (スコア:0)
反論ではありません。あなたの話が筋違いという指摘です。
> Xの仕組みを知らず、Xが遅いという勝手な思い込みの下、SDLが特別なソフ
> トであるように誤解し、あさっての方向の議論をしているようにしか見えま
> せん。
あなたが書いていることは当たり前のことばかりです。もともとの議論者が前
提にして書くまでもないことを、ただ書いているだけです。
御自分の知識を披露したくなるのは自由ですが、当たり前の話を省略している
議論の参加者に対して、「Xの仕組み、わかっていますか?」とおっしゃっても
的外れです。むしろ議論に対してノイ
Re:Xの仕組み、わかっていますか? (スコア:0)
今までの議論を眺めていたあんまり詳しくないACです。
XShmでは、ビデオカードのVRAMも共有できる仕組みがあるんでしょうか。 クライアントがメインメモリに描画しなければならないのでは、リアルタイム系のアプリは致命的に遅くなると思うんですが。
Re:Xの仕組み、わかっていますか? (スコア:0)
>じゃあ、一体何が問題なんですか? 何も問題ないんじゃないでしょうか。
論点がずれてるような...
X>VNCかVNC>Xかが問題じゃなくて、
ローカル直書き(のよう)な描画>>Xであることが問題だという話でしょう。
#もうちょっと細かくいうと
#
#ローカル直書き(のよう)な描画>>X(ローカルモード:X serverとX clientが同じマシン上)>X(ネットワークモード:X serverとX clientが異なるマシン上)>VNC
#
#ということか。
で、ローカル直書き(のよう)な描画>>Xの原因として、ネットワークを意識した、ク
Re:Xの仕組み、わかっていますか? (スコア:0)
>> か? 説明してください。
>
>どうしてX上のblitしか使わないSDLがここで出てくるのですか?
>誰もそんな議論はしていません。読む気が無いのでしたら、最初から書かないで下さい。
(#501175)と、(#501249)を書いたやつは誰だ?
話を収束させてくれ。
Re:Xの仕組み、わかっていますか? (スコア:0)
XにはDGAというアプリケーションがVRAMに直接アクセスしてローカル直書きできる
仕組みがあります。だから、そんな問題は最初から存在しません。
そもそも、画面が一つしかなくVRAMも基本的には一つしかない以上、画面を分割して
Windowとして複数のアプリケーションに提供するWindows Systemでは、アプリケーション
からの描画要求を単一のプログラムが受け取り一括して処理するか、アプリケーション
間でロック等を使って描画処理を調停するしか方法がないわけです。
後者では行儀の悪いアプリ
Re:Xの仕組み、わかっていますか? (スコア:0)
間違いを認めたくないから暴れているだけのDQN。
Re:Xの仕組み、わかっていますか? (スコア:1)
DirectXではVRAMに直接描画するよりメインメモリに描画してからblitするほうが平均的に速い。
直接描画したいというからには標準のblit等ではできない特殊処理とかで何度もread/writeすると思いますが、
外部バスの(たぶん)非キャッシュ領域にせこせこアクセスするより、メインメモリで処理して転送はGPUに任せたほうが速いんでしょう。
一部だけ書き換えるんだったら一部だけblitすればいいし
もちろん本当にごく一部(1pixelとか)だったらGPU駆動のオーバーヘッドのほうが大きいだろうけど
Re:Xの仕組み、わかっていますか? (スコア:1)
あげ足取りのようで申し訳ないのですが, 『Xに問題があるからDGA拡張が出来た』とも言えますよね.
で, 現状のDGA拡張は(慣れの問題かもしれませんが)同じような機能を持つSGIのGL拡張よりも使いづらいですし, 『まだまだ』なレベルだと思っています. なので現状でXに速度的な問題があるというのは間違いでないと思いますが.
個人的には次世代のXでもこのYでもここら辺の問題をクリアしてくれるのであれば歓迎ですね.
Re:Xの仕組み、わかっていますか? (スコア:0)
>SDLはXImageやXShmを使ったただのライブラリですよ。Xのblitをそのまま使っています。
Linuxでフレームバッファ経由でDirectFB [directfb.org]を使っている人は無視ですか:-P
#ここのコメントツリーで、Xマンセーの人に聞いてみたいけど、DirectFBとかのアプローチって意味無しですか?
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中だけの変換&合成で終わらない?
終わるでしょう。