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

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

  • 各ウィンドウがフロントバッファを直接描きかえるのではなく、まずバックバッファに描画するようになるらしいのが目玉なんだと思います。(Mac OS Xではすでにそうなってるんでしょうか?)

    グラフィックプロセッサの性能が上がったので、必死でWM_PAINTを投げて差分描画するような、言ってみれば泥臭いことをせずに、より自然な方法でデスクトップ画面を合成しようと。今のWindowsでは、重いアプリケーションの上でウィンドウを動かしたときに再描画が遅れて一時的に化けたりしますが、そういった不快な部分がなくなるんじ
    • 各ウィンドウがフロントバッファを直接描きかえるのではなく、まずバックバッファに描画するようになるらしいのが目玉なんだと思います。(Mac OS Xではすでにそうなってるんでしょうか?)

      裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。もし、アプリケーションが直接フロントを書きかえたつもりでいても、バックバッファ→フロントバッファというルーティングが自動的に踏まれるのであれば、余計なお世話な気もしますけど。

      # もし、ピントがずれたことを言ってたらごめんなさい...

      今回の件で言うと

      --

      -- cooper

      • > 裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。

        3D CAD みたいな、グラフィックアクセラレータの性能をフル活用しようとするアプリケーションの場合、メモリに書き出してから BitBlt だとハードウェアアクセラレーションが効かなくなるため、描画がとても遅くなってしまいます。
        そのため従来は描画領域が無効化されるたびに再描画するか、もしくはほったらかしにして他のウィンドウが重なった部分は真っ白のままほったらかしにするのが通例でした。

        この技術が搭載されると、こういったアプリケーションで表示領域の破壊が起こらないので再描画の必要がなくなり、高速で且つ表示がキモチワルイことにならないというありがたい恩恵が受けられるようになります。

        # 個人的にはこの新しい技術を GUI 側が活用する場合の、アプリケーション開発者ではないユーザーが受けられる恩恵ってのも十分に気になるわけですが。。。WinHEC なんだからその辺は気にするなってのはこういうことだったのかなぁ。

        --
        むらちより/あい/をこめて。
        親コメント
        • 3D CAD みたいな、グラフィックアクセラレータの性能をフル活用しようとするアプリケーションの場合、メモリに書き出してから BitBlt だとハードウェアアクセラレーションが効かなくなるため、描画がとても遅くなってしまいます
          そうなんですか? 3D CAD は作ったことがないので良くわかってませんが、直接描画が通例なんですか?
          この技術が搭載されると、こういったアプリケーションで表示領域の破壊が起こらないので再描画の必要がなくなり、高速で且つ表示がキモチワルイことにならないというありがたい恩恵が受けられるようになります
          表示領域の破壊と再描画は、ウィンドウの重なり以外にも、スクロールやリサイズ等で発生しますよね。こういった場合の再描画処理は依然として必要だし、アプリケーションの責任だと思います。

          もしかして、これを OS が勝手にやってくれるって話だったりしますか?
          --

          -- cooper

          親コメント
          • 表示領域の破壊と再描画は、ウィンドウの重なり以外にも、スクロールやリサイズ等で発生しますよね。こういった場合の再描画処理は依然として必要だし、アプリケーションの責任だと思います。

            もしかして、これを OS が勝手にやってくれるって話だったりしますか?

            そう。。。なんですか?(w 描画領域の大きさが固定で現実的な大きさなら、やってくれそうな気もしますが。。。

            教えてエライ人!!(w

            --
            むらちより/あい/をこめて。
            親コメント
            • 今回のでそうはならないんじゃないかとは思いますが、
              そういう仕組みを考えてみるのはすごく面白いことだと思います。

              そういう、スクロールやフレームサイズの変更など、GUI操作をすべてGPUに任せてしまえると考えると、CPUは本来の仕事に集中できるわけで、それこそ本来そうなっているべきことなんじゃないかな?
              親コメント
          • by G7 (3009) on 2003年05月10日 22時48分 (#313322)
            >表示領域の破壊と再描画は、ウィンドウの重なり以外にも、スクロールやリサイズ等で発生しますよね。こういった場合の再描画処理は依然として必要だし、アプリケーションの責任だと思います。

            アプリと実際の画面の間のInterfaceがビットマップ絵ベースであるならば、
            責任はアプリに有る…というか「アプリ以外(OSやドライバ)に責任を負わせても、あんまりパフォーマンスアップに繋がらない」
            のでしょうね。

            Interfaceがそれ以外のものになると、話は変わってくるんじゃないかな。
            たとえばベクトル絵ベースになると、拡大縮小回転の要求を「いちいちアプリに投げなくても」
            OSとかドライバとかが独自判断(?)して再描画させられる。

            つまり、反射神経(OSやドライバ)が持つ機能(とそれへのInterface)を拡張することで、
            大脳(=アプリ)が高度な判断を毎回やる必要性を減らし、
            その分だけ全体としての負荷を減らすことは出来る、という感じなんじゃないかと。

            まあ別の部分では負荷が却って増えてしまうけど、
            「今時のハードだと」どの部分の負荷を受け持つ(そして改善する)のが得意か?は
            年々変化しているのでしょうから(それが例えば画面アクセラレータ)。

            #手(小脳)が考えてキーボードを叩く(意識なんて殆ど介在しない)のでG7。
            #なおスラドのコメントはいちいち大脳が判断して書いているようです。まあその大脳がこの性能ではアレですが(藁
            親コメント
            • たとえばベクトル絵ベースになると、拡大縮小回転の要求を「いちいちアプリに投げなくても」
              OSとかドライバとかが独自判断(?)して再描画させられる
              なるほど。僕にはこういう描画処理を具体的にイメージする能力がないんですね。旧態依然とした、bitblt しか思いつかないってのがそのあらわれでして...

              Direct X でも Flip とか Blt とか Present とかのメソッドを発見していたので、そこから先に進むことができずにいたようです。興味深いコメントでピリリと刺激されました。どうもです。
              --

              -- cooper

              親コメント
          • >もしかして、これを OS が勝手にやってくれるって話だったりしますか?

            ハードウェア(=GPU)がやってくれます。
            OS(APIかな?)はその機能を簡単に利用できるようにするだけです。
            (少なくとも今のDirectXの初期化より簡単にはなるはず)
            • >もしかして、これを OS が勝手にやってくれるって話だったりしますか?

              ハードウェア(=GPU)がやってくれます。
              OS(APIかな?)はその機能を簡単に利用できるようにするだけです。
              「これ」=「スクロールやリサイズで無効になったクライアント矩形の再描画」のつもりだったんですが、確かに GPU がやってくれますね、最終的には :-)

              ううむ。

              # ああもうなにがなんだか...
              --

              -- cooper

              親コメント

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

処理中...