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

MicrosoftがLonghornの3DUI公開」記事へのコメント

  • 個人的にはアプリケーションのスケーリングがうれしいですね。

    はっきりいって2Dのディスプレイに3Dのインタフェースを書き出すのは逆に使いにくくなると思います。タレコミにあった3D Desktop?なんかはかなり使いにくそう。3Dっぽい効果くら
    • by Anonymous Coward on 2003年05月09日 20時43分 (#312613)

      半透過ウィンドウは Windows 2000 の時点で API 用意されてますが。

      ただ、極端に処理が遅くなるため、Longhorn ではここまで軽量に処理できるようになりましたよ、という事を見せるのがポイントでしょう。

      親コメント
      • by Y.. (7829) on 2003年05月09日 21時17分 (#312646) 日記
        半透過Windowの描画が軽くなったら軽くなったで

        裏に隠れたWindowの描画をはしょれなくなっちゃうからそのぶんだけ重くなりそうですねぇ
        今回は裏のWindowを頻繁に書き換えるやつじゃなかったからそこら辺は露呈しなかったんでしょうけど

        次にデモやるときは ムービー3つぐらい重ねて重くならないことをアピールしてほしいもんです
        親コメント
        • おのおののWindowの描画をはしょらなくしますよ,
          というデモなんですけどね.
          • うん。わかってない人多いっすよね。

            このシステムが実現するとなにがおこるか、というと、 プログラムに「再描画」の処理がいらなくなるのです。 その内容が破壊されないことをシステムが保障して、 複雑な再合成処理は下層(ハード)のお仕事。

            まあ、アプリケーションとしては、従来環境のためと、 あと初回の描画のために OnPaint 処理をき

            • ごめんなさい、これってソースどこでしょう?興味津々。
              #たれ込みのリンク先にあったかな?

              これが本当だとすると、各バッファ(ウィンドウ)の描画内容をどこかでメモリに保存する必要があると思うんですが、それはOSがやってくれるわけでしょうか?
              でもそれって、鬼ほどメモリ食べるのでは…?

              あるいはメモリが足りなくなったときとかは、どうなるんでしょう?
              #再描画が呼ばれる頻度が減る、くらいなら理解できるけど…
              親コメント
              • 今のPCには「鬼ほど」描画メモリがあるのです。

                ですから有効に使いましょうということで、いわゆる富豪プログラミングですね。
                親コメント
              • by G7 (3009) on 2003年05月10日 21時42分 (#313291)
                >これが本当だとすると、各バッファ(ウィンドウ)の描画内容をどこかでメモリに保存する必要があると思うんですが、それはOSがやってくれるわけでしょうか?
                >でもそれって、鬼ほどメモリ食べるのでは…?

                120%うろ覚えですが、たしかBeOSだかも、既にそれをやってるとか言ってませんでしたっけ?

                必要メモリっすか?俺も素人(ぉ)なんで乱暴すぎる推測ですが、
                n個の窓(デスクトップ含む)が最大化状態の自分の描画結果を保持してるとすると、
                1024*768(笑)*4(Pixelが32bitだとして)*n byteが有ればいい、のだよねえ?
                だとすると3MB*n。
                まあ今時(のWinユーザー)なら許せるんじゃない?
                100MBくらいの余剰メモリ空きが(メイン)メモリにあるのは珍しいことじゃないんだから。

                #自分のpc(win)にゃbcがinstallされてないので焦ったが、ruby -eで済むことに気付いて助かりました(ぉ

                >あるいはメモリが足りなくなったときとかは、どうなるんでしょう?

                俺のほうでは、仕事鯖Unixマシンのメインメモリ(swap込みでも)が頻繁に「足りなく」なっていたんですけど(笑)。
                つまり、足りなくなったら動かなくなる、ってのは大昔からのコンピュータの仕様なのではないかと。

                絵の管理ポリシーが空きメモリに合わせて動的に替わるように作ってあるかどうかは、知りません。
                #でもメモリが不足がちなときにアプリに頻繁な再描画を強いると、悪循環になりそう。
                親コメント
              • 各ウィンドウの描画内容は1つのテクスチャとして保存されると予想されます.
                だから,3Dなんて言われてるわけですが.

                要求スペックを見ると,ビデオメモリは充分にあると思いますが,
                不足した場合の挙動は確かに気になります.
                DirectXのレベルでうまく扱ってくれるのかもしれません.
              • > ごめんなさい、これってソースどこでしょう?興味津々。 > #たれ込みのリンク先にあったかな? 元記事に「別々のバッファに。。。」と書かれてるような。。。
              • 多重バッファの話じゃなくて、再描画処理がなくなる、というところです。
                親コメント
              • 例えばXGA 32bitsカラーだと、1024x768x32/8=3MBになりますよね。RADEON 9x00あたりで256MBだから、85バッファしか稼げなくなります。85枚だとあきらかに不足だと思うんですが。
                あとゲームのように、VGAカードにくっついたビデオメモリを使って高速化しているアプリが居れば、さらに使えるバッファは減りますし。

                #まあシステムメモリから回すとかスワップするとか手はあるけど…
                親コメント
              • by coco-natade (13903) on 2003年05月10日 14時18分 (#313117)
                「・・・85枚だとあきらかに不足だと思うんですが」

                こういうときのためのAGP8xなんでしょうね?
                8x。

                ・・・なんで8xなんだよ!
                内蔵AGP4x買ったばっかなのに。
                親コメント
              • ウィンドウ単位で保持されるのだからXGAサイズが85枚で不足、というのは間違ってませんか?
                親コメント
              • 多重バッファの話=再描画処理がなくなる
                アプリの責任でない描画領域の破壊が起こらないため、
                再描画をしなくてよいということになります。
              • (ぉ)って何ですか?
              • ええ、まあ概算というか極論ですね。
                でもブラウザやワードの要に全画面表示なアプリで85枚ならあり得るかなあ、と思います。

                たぶん、1バッファあたりはもっと少ないでしょうね。その代わり、使われるバッファは実際には200バッファくらいは軽く越えるんじゃないでしょうか。
                親コメント
              • 言われてみれば、何故に多重バッファなのか考えれば分かることですが…。
                間抜けにもさっぱり気づきませんでした。
                3Dアクセラレータの使い倒そう→窓描画=テクスチャ描画、
                という流れだと読んでいて、「それでどうなるの?」の方は
                「あー、ぐるぐる回ったり変形させたり自由自在なんだ。ふーん」
                くらいで思考止まってました。

                いやもう、まさに枝タイトルの通り、分かってない人でした。はい。
                親コメント
              • 一人ツッコミ、くらいの意味じゃなかったでしたっけ。たぶん。
                いや、私もよく使いますけど(ぉ

                #と、このように

                #まーともかく、とりあえずLonghornで早くプログラム組んでみたいなあ
                #てことでファイナルアンサー。
                #うーん、いいデモだ。
                親コメント
            • あ~ そこまで説明はいるとわかりやすいな
              どーも3Dに視点がいっちまってそこまで頭が回ってなかった

              アプリから見ると描画に関してはずっと最前面で動いてるのと同じになるわけだ
              初期化してあとは本当に必要なところを書き換えるだけでいいわけだ
              でも 親windowレベルの話だったらちょっと物足りないかもしれないな
              タブで子window切り替えとかやってると結局子windowの描画処理書かなきゃならんし

              まぁそれでも 確かに進化してる
              2000→XPみたいなバージョンアップとはあきらかに違ってくるわけだ
              親コメント
            • これはXで言うところのBacking Store/Save Underと同じようなものでしょうか? Xサーバはユーザプロセスでメモリ使い放題なので, 10年前から実現されていましたけど.

              親コメント
            • > プログラムに「再描画」の処理がいらなくなるのです。

              全アプリが、VBのフォームのAutoRedrawプロパティをTrueにしたようなもんですな。

              # メモリは食うけど、サンデープログラマの使い捨てプログラムには強い味方。
      • by Anonymous Coward
        >極端に処理が遅くなるため

        ディスプレイドライバをリリースしているベンダーに文句を言いましょう。ドライバレベルの仕様ではそういう機能が定義されているのにだーれも実装しなかったんだ。

犯人はmoriwaka -- Anonymous Coward

処理中...