パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Y Window Systemプロジェクト進行中」記事へのコメント

  • このニュースが本家に掲載された時に、
    「あれ、随分昔に Y Window system って無かったっけか?」
    と不思議に思ってました。で、さっきやっと発見。

    The Y Window System [hungry.com]

    1998年から更新が無いようです。

    「Xにとって代わるもの」の候補は他にもいろいろ名乗りを上げています
    が、上の初代 Y Windows System のように最早忘れ去られているものも
    ある状態。この Y はどうですかね?

    ところで、Yの
    • by Anonymous Coward
      X11のように、GUIクライアントプログラムがサーバと
      クライアントで分断されてるデザインはさすがに時代遅れと思いますね。
      full colorの画面を表示するためだけに何度無駄なコピーが発生することやら。
      それに1画面3MBの転送を100BaseTで送ったら、3fpsしか出ないよ。

      そろそろ、クライアントロジックと表示が分断さ
      • Xの限界は10年近く前から言われてきているので今更な感じもあるのですが, remoteへの表示なのかlocalなのか切り分けて考えないと論点がぼやけますよ.

        タイトな表示をさせようとしたら Xの場合localでやってもきついのに Ether越しの例を出しても……
        最近のXも頑張ってはいると思うんですけどね.

        VNCや「リモートデスクトップ接続」などのアプローチでいいじゃん。

        VNCの方が遅くないですか?
        VNCって全画面分飛ばすんですよね? それならapplicationごとにやり取りでき

        • by Anonymous Coward
          > タイトな表示をさせようとしたら Xの場合localでやってもきついのに Ether越しの例を出しても……
          > 最近のXも頑張ってはいると思うんですけどね.

          ウィンドウシステムのレンダリングに、サーバクライアントモデルが意味が無い、という話です。
          サーバクライアントモデルがある限り、それが足枷となってローカルの描画はどんなに頑張ってもダメダメ。
          もう何年も言われていることですが、端末のGPUの描画性能が年々上がっていくにつれ、
          乖離が激しくなっています。どんどん要求は高まっているのです。

          > VNCの方が遅くないですか?
          > VNCって全画面分飛ばすん
          • サーバクライアントモデルがある限り、それが足枷となってローカルの描画はどんなに頑張ってもダメダメ。

            ここについては全く同意見です.
            それを解決するためにXも拡張していっているんですけどね. まぁまだまだ満足できるレベルではないですが.
            この辺の問題はX上で大きな動画などを表示しようとすると 顕著に出ますからね.

            VNCは画面更新された部分だけを転送します。

            だからでかいWindowを動かしたりすると たまらないくらい遅いわけ

            • > それを解決するためにXも拡張していっているんですけどね. まぁまだまだ
              > 満足できるレベルではないですが. この辺の問題はX上で大きな動画などを
              > 表示しようとすると 顕著に出ますからね.

              そうですね。たとえばXにFlashやSVGレンダリングを追加してもいいのでしょ
              うが、結局blitがダメダメな時点で、しょせんは付け焼刃に過ぎないと思いま
              す。

              >>>> # OpenGLやSDL使えって?ゲームならいいだろうけど…
              >>> SDLはともかくOpenGL使ってXの描画が早くな
              • by Anonymous Coward on 2004年02月23日 18時48分 (#501298)
                間違った認識で議論しても適切な議論にならないので、かなり長文になりますが、
                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拡張というのもあります。
                親コメント
              • > Xも更新された部分だけ処理するし、

                勘違いかと思いますが、Xはexposeされた部分を転送するのに対し、VNC は更
                新された部分を転送します。もちろん、たいていの場合はXの方が速いですよ。

                > ローカルでは画像データをXサーバとXクライアントの共有メモリに置き、サー
                > バとクライア
              • > 勘違いかと思いますが、Xはexposeされた部分を転送するのに対し、VNC は更
                > 新された部分を転送します。もちろん、たいていの場合はXの方が速いですよ。

                意味不明。どう意味ですか?

                XクライアントがExpose Eventをどう処理するかはアプリケーションの自由なんですが。

                また、XクライアントがまじめにExpose eventを処理しているという前提で、VNCの方が
                速くなる具体例を出してください。

                > shmも含めて不可避なコピー回数が共通の問題点という認識です。

                これもよくわかりません。

                XではXクライアントとXサーバ間のデータ転送には手間がかかります。#501298で
              • > 意味不明。どう意味ですか?

                どうぞ。VNC Documentation [realvnc.com]

                > XクライアントがまじめにExpose eventを処理しているという前提で、VNCの
                > 方が 速くなる具体例を出してください。

                議論の中では「VNCでも代替になる」というのが主旨で、これは枝葉末節に過
                ぎないことを最初にお断りしておきます。

                たとえば、SVGで白地に簡単な図形をレンダリングした結果を複数個、連続領
                域に転送する場合、VNCは結果をまとめて圧縮をかけて転送します(先ほどのURL
                にプロトコルの仕様書があります)。この場合はVNCが勝つかもしれません。と
                はいえ、適切に最適化されたXクライアントにVNCが勝つ
              • えっと、長いので整理すると、VNCよりXの方がいいってことでいい?

                # 外野から見ていた利用者の立場
              • いや、整理するとXの描画は最近我慢ならないほど遅いよね。
                って話です。XとVNCの比較ではないです。そもそもXは駄目って話。
              • > たとえば、SVGで白地に簡単な図形をレンダリングした結果を複数個、連続領
                > 域に転送する場合、VNCは結果をまとめて圧縮をかけて転送します

                レンダリングしたデータをどうXサーバに転送するかはクライアントが決めることができる
                ので、当然Xでもまとめて転送できます。また、Xには圧縮して転送する拡張もあります。

                VNCでは更新されている部分をVNCが探して転送しないといけません。

                そのため、Xクライアントが最適化されているなら、更新部分を探さなくて済む分、Xの方が
                圧倒的に速くなります。

                したがって、Xの方が仕組み上優れているということになります。
              • XShmを使ったゲームの仕組み。SDLでも同じです。

                まず、Xクライアントは表示用のWindowを作り、ゲーム画面に対応するデータ領域をX
                サーバとの共有メモリとして確保します。この領域はXクライアントからは普通にメモリ
                として直接アクセスでき、Xサーバからもメモリとして直接アクセスできます。

                Xクライアントは対応するデータ領域に直接ゲーム画面を書き込み、この領域を更新する
                ようにXサーバに通知します。すると、Xサーバはこの更新領域に直接アクセスできるので、
                BitBlt等を使って、ビデオカードに転送し、表示します。

                したがって、
                >> XではXクライアントとXサーバ
              • 補足。

                実際にやったことないし、現実にそういうことをするライブラリがあるかどうかわかり
                ませんが、Pixmapにも同じ拡張があります。

                jpegファイルを表示するプログラムでは、表示用のWindowを作り、jpegファイルを展開
                するPixmapをXサーバとの共有メモリとして作ります。この領域は、クライアントからも、
              • > 全く反論になっていませんが。

                反論ではありません。あなたの話が筋違いという指摘です。

                > Xの仕組みを知らず、Xが遅いという勝手な思い込みの下、SDLが特別なソフ
                > トであるように誤解し、あさっての方向の議論をしているようにしか見えま
                > せん。

                あなたが書いていることは当たり前のことばかりです。もともとの議論者が前
                提にして書くまでもないことを、ただ書いているだけです。

                御自分の知識を披露したくなるのは自由ですが、当たり前の話を省略している
                議論の参加者に対して、「Xの仕組み、わかっていますか?」とおっしゃっても
                的外れです。むしろ議論に対してノイ
              • 今までの議論を眺めていたあんまり詳しくないACです。

                XShmでは、ビデオカードのVRAMも共有できる仕組みがあるんでしょうか。 クライアントがメインメモリに描画しなければならないのでは、リアルタイム系のアプリは致命的に遅くなると思うんですが。

              • 別ACですが。

                >じゃあ、一体何が問題なんですか? 何も問題ないんじゃないでしょうか。

                論点がずれてるような...
                X>VNCかVNC>Xかが問題じゃなくて、
                ローカル直書き(のよう)な描画>>Xであることが問題だという話でしょう。

                #もうちょっと細かくいうと
                #
                #ローカル直書き(のよう)な描画>>X(ローカルモード:X serverとX clientが同じマシン上)>X(ネットワークモード:X serverとX clientが異なるマシン上)>VNC
                #
                #ということか。

                で、ローカル直書き(のよう)な描画>>Xの原因として、ネットワークを意識した、ク
              • >> もう一度聞きます。SDLがどうして通常のXクライアントより速くなるんです
                >> か? 説明してください。
                >
                >どうしてX上のblitしか使わないSDLがここで出てくるのですか?
                >誰もそんな議論はしていません。読む気が無いのでしたら、最初から書かないで下さい。

                (#501175)と、(#501249)を書いたやつは誰だ?
                話を収束させてくれ。
              • > ローカル直書き(のよう)な描画>>Xであることが問題だという話でしょう。
                XにはDGAというアプリケーションがVRAMに直接アクセスしてローカル直書きできる
                仕組みがあります。だから、そんな問題は最初から存在しません。

                そもそも、画面が一つしかなくVRAMも基本的には一つしかない以上、画面を分割して
                Windowとして複数のアプリケーションに提供するWindows Systemでは、アプリケーション
                からの描画要求を単一のプログラムが受け取り一括して処理するか、アプリケーション
                間でロック等を使って描画処理を調停するしか方法がないわけです。

                後者では行儀の悪いアプリ
              • (#501175)と(#501249)と(#501667)は同一ACだろ。

                間違いを認めたくないから暴れているだけのDQN。
              • DGAは知らんが
                DirectXではVRAMに直接描画するよりメインメモリに描画してからblitするほうが平均的に速い。
                直接描画したいというからには標準のblit等ではできない特殊処理とかで何度もread/writeすると思いますが、
                外部バスの(たぶん)非キャッシュ領域にせこせこアクセスするより、メインメモリで処理して転送はGPUに任せたほうが速いんでしょう。
                一部だけ書き換えるんだったら一部だけblitすればいいし
                もちろん本当にごく一部(1pixelとか)だったらGPU駆動のオーバーヘッドのほうが大きいだろうけど
                親コメント
              • それにXのDGA拡張で問題が解決するなら、Xに問題があるわけではないと言うことになります。

                あげ足取りのようで申し訳ないのですが, 『Xに問題があるからDGA拡張が出来た』とも言えますよね.
                で, 現状のDGA拡張は(慣れの問題かもしれませんが)同じような機能を持つSGIのGL拡張よりも使いづらいですし, 『まだまだ』なレベルだと思っています. なので現状でXに速度的な問題があるというのは間違いでないと思いますが.

                個人的には次世代のXでもこのYでもここら辺の問題をクリアしてくれるのであれば歓迎ですね.

                親コメント
              • チャチャ

                >SDLはXImageやXShmを使ったただのライブラリですよ。Xのblitをそのまま使っています。

                Linuxでフレームバッファ経由でDirectFB [directfb.org]を使っている人は無視ですか:-P

                #ここのコメントツリーで、Xマンセーの人に聞いてみたいけど、DirectFBとかのアプローチって意味無しですか?
              • データがどんどん沸いてくるストリームは別だけど、
                そうでない場合は、あらかじめテクスチャをVRAM上に溜め込んでおいて、
                描画処理はほとんどGPU中だけの変換&合成で終わらない?
                ところでこれ最近のXで出来るの?>詳しい人
              • SDLにはそういう機能がある。XのSDLでSDL_HWSURFACEを使った場合に、本当に、VRAM上に
                サーフィスを確保してくれるのか知らないが。

                それに、VRAMでなくメインメモリにテクスチャを置いても、GPUはメインメモリからVRAMに
                blitできるから、GPUだけで処理できると思われ。

                メインメモリ→VRAMのblitとVRAM→VRAMのblitでどのくらい速度が違うかは知らない。
              • > SDLにはそういう機能がある。

                API見たけど、その際に回転も拡大もα以外の合成もしてくれないみたい。しょぼん。

                > VRAMでなくメインメモリにテクスチャを置いても、GPUはメインメモリからVRAMに
                > blitできるから、GPUだけで処理できると思われ。

                GPUがマスタのDMAでも、CPUはその間メモリ見にいけないから、やっぱりしょぼん。

                > メインメモリ→VRAMのblitとVRAM→VRAMのblitでどのくらい速度が違うかは知らない。
              • 比較しているレイヤが違うような。
                単純な2Dのbitblt/mask程度だったら
                あらかじめビットマップをXのPixmap(WindowsでいうところのGDIのDDB)でシステムに溜め込んでおいて(VRAMに乗るかメモリに乗るかはシステム依存)GPUで終わると思うし、

                回転拡大縮小αとかするのであれば、3Dのハードとドライバがあれば、(X上の)OpenGLあるいはDirect3Dで
                >あらかじめテクスチャをVRAM上に溜め込んでおいて、
                >描画処理はほとんどGPU中だけの変換&合成で終わらない?
                終わるでしょう。
                親コメント

※ただしPHPを除く -- あるAdmin

処理中...