アカウント名:
パスワード:
各ウィンドウがフロントバッファを直接描きかえるのではなく、まずバックバッファに描画するようになるらしいのが目玉なんだと思います。(Mac OS Xではすでにそうなってるんでしょうか?)
裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。もし、アプリケーションが直接フロントを書きかえたつもりでいても、バックバッファ→フロントバッファというルーティングが自動的に踏まれるのであれば、余計なお世話な気もしますけど。 # もし、ピントがずれたことを言ってたらごめんなさい... 今回の件で言うと
-- cooper
> 裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。
3D CAD みたいな、グラフィックアクセラレータの性能をフル活用しようとするアプリケーションの場合、メモリに書き出してから BitBlt だとハードウェアアクセラレーションが効かなくなるため、描画がとても遅くなってしまいます。 そのため従来は描画領域が無効化されるたびに再描画するか、もしくはほったらかしにして他のウィンドウが重なった部分は真っ白のままほったらかしにするのが通例でした。
この技術が搭載されると、こういったアプリケーションで表示領域の破壊が起こらないので再描画の必要がなくなり、高速で且つ表示がキモチワルイことにならないというありがたい恩恵が受けられるようになります。
# 個人的にはこの新しい技術を GUI 側が活用する場合の、アプリケーション開発者ではないユーザーが受けられる恩恵ってのも十分に気になるわけですが。。。WinHEC なんだからその辺は気にするなってのはこういうことだったのかなぁ。
3D CAD みたいな、グラフィックアクセラレータの性能をフル活用しようとするアプリケーションの場合、メモリに書き出してから BitBlt だとハードウェアアクセラレーションが効かなくなるため、描画がとても遅くなってしまいます
この技術が搭載されると、こういったアプリケーションで表示領域の破壊が起こらないので再描画の必要がなくなり、高速で且つ表示がキモチワルイことにならないというありがたい恩恵が受けられるようになります
表示領域の破壊と再描画は、ウィンドウの重なり以外にも、スクロールやリサイズ等で発生しますよね。こういった場合の再描画処理は依然として必要だし、アプリケーションの責任だと思います。 もしかして、これを OS が勝手にやってくれるって話だったりしますか?
表示領域の破壊と再描画は、ウィンドウの重なり以外にも、スクロールやリサイズ等で発生しますよね。こういった場合の再描画処理は依然として必要だし、アプリケーションの責任だと思います。
もしかして、これを OS が勝手にやってくれるって話だったりしますか?
そう。。。なんですか?(w 描画領域の大きさが固定で現実的な大きさなら、やってくれそうな気もしますが。。。
教えてエライ人!!(w
たとえばベクトル絵ベースになると、拡大縮小回転の要求を「いちいちアプリに投げなくても」 OSとかドライバとかが独自判断(?)して再描画させられる
>もしかして、これを OS が勝手にやってくれるって話だったりしますか? ハードウェア(=GPU)がやってくれます。 OS(APIかな?)はその機能を簡単に利用できるようにするだけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
ダブルバッファリング (スコア:2, 興味深い)
グラフィックプロセッサの性能が上がったので、必死でWM_PAINTを投げて差分描画するような、言ってみれば泥臭いことをせずに、より自然な方法でデスクトップ画面を合成しようと。今のWindowsでは、重いアプリケーションの上でウィンドウを動かしたときに再描画が遅れて一時的に化けたりしますが、そういった不快な部分がなくなるんじ
Re:ダブルバッファリング (スコア:1)
裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。もし、アプリケーションが直接フロントを書きかえたつもりでいても、バックバッファ→フロントバッファというルーティングが自動的に踏まれるのであれば、余計なお世話な気もしますけど。
# もし、ピントがずれたことを言ってたらごめんなさい...
今回の件で言うと
-- cooper
Re:ダブルバッファリング (スコア:1)
> 裏 Memory に一旦描画して一気に bitblt するという手法は Windows に限らず一般的かなぁと思います。
3D CAD みたいな、グラフィックアクセラレータの性能をフル活用しようとするアプリケーションの場合、メモリに書き出してから BitBlt だとハードウェアアクセラレーションが効かなくなるため、描画がとても遅くなってしまいます。
そのため従来は描画領域が無効化されるたびに再描画するか、もしくはほったらかしにして他のウィンドウが重なった部分は真っ白のままほったらかしにするのが通例でした。
この技術が搭載されると、こういったアプリケーションで表示領域の破壊が起こらないので再描画の必要がなくなり、高速で且つ表示がキモチワルイことにならないというありがたい恩恵が受けられるようになります。
# 個人的にはこの新しい技術を GUI 側が活用する場合の、アプリケーション開発者ではないユーザーが受けられる恩恵ってのも十分に気になるわけですが。。。WinHEC なんだからその辺は気にするなってのはこういうことだったのかなぁ。
むらちより/あい/をこめて。
Re:ダブルバッファリング (スコア:1)
もしかして、これを OS が勝手にやってくれるって話だったりしますか?
-- cooper
Re:ダブルバッファリング (スコア:1)
そう。。。なんですか?(w 描画領域の大きさが固定で現実的な大きさなら、やってくれそうな気もしますが。。。
教えてエライ人!!(w
むらちより/あい/をこめて。
Re:ダブルバッファリング (スコア:1)
そういう仕組みを考えてみるのはすごく面白いことだと思います。
そういう、スクロールやフレームサイズの変更など、GUI操作をすべてGPUに任せてしまえると考えると、CPUは本来の仕事に集中できるわけで、それこそ本来そうなっているべきことなんじゃないかな?
Re:ダブルバッファリング (スコア:1)
アプリと実際の画面の間のInterfaceがビットマップ絵ベースであるならば、
責任はアプリに有る…というか「アプリ以外(OSやドライバ)に責任を負わせても、あんまりパフォーマンスアップに繋がらない」
のでしょうね。
Interfaceがそれ以外のものになると、話は変わってくるんじゃないかな。
たとえばベクトル絵ベースになると、拡大縮小回転の要求を「いちいちアプリに投げなくても」
OSとかドライバとかが独自判断(?)して再描画させられる。
つまり、反射神経(OSやドライバ)が持つ機能(とそれへのInterface)を拡張することで、
大脳(=アプリ)が高度な判断を毎回やる必要性を減らし、
その分だけ全体としての負荷を減らすことは出来る、という感じなんじゃないかと。
まあ別の部分では負荷が却って増えてしまうけど、
「今時のハードだと」どの部分の負荷を受け持つ(そして改善する)のが得意か?は
年々変化しているのでしょうから(それが例えば画面アクセラレータ)。
#手(小脳)が考えてキーボードを叩く(意識なんて殆ど介在しない)のでG7。
#なおスラドのコメントはいちいち大脳が判断して書いているようです。まあその大脳がこの性能ではアレですが(藁
Re:ダブルバッファリング (スコア:1)
Direct X でも Flip とか Blt とか Present とかのメソッドを発見していたので、そこから先に進むことができずにいたようです。興味深いコメントでピリリと刺激されました。どうもです。
-- cooper
Re:ダブルバッファリング (スコア:0)
ハードウェア(=GPU)がやってくれます。
OS(APIかな?)はその機能を簡単に利用できるようにするだけです。
(少なくとも今のDirectXの初期化より簡単にはなるはず)
Re:ダブルバッファリング (スコア:1)
ううむ。
# ああもうなにがなんだか...
-- cooper