アカウント名:
パスワード:
各ウィンドウがフロントバッファを直接描きかえるのではなく、まずバックバッファに描画するようになるらしいのが目玉なんだと思います。(Mac OS Xではすでにそうなってるんでしょうか?)
-- 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)
>まずバックバッファに描画するようになるらしいのが目玉なんだと
>思います。(Mac OS Xではすでにそうなってるんでしょうか?)
固まったアプリの上に別のウィンドウを移動しても白くならないってやつですよね。
それって、Mac OS Xどころか、NEXTSTEP時代からずっとそうでしたが…。
自分が見たのは1995年ですが、もっと昔から実装してたかも。
# 半透明もDisplay PostScriptで実装してたらしい。
# 本当かどうかは知らん。
Re:ダブルバッファリング (スコア:1)
# もし、ピントがずれたことを言ってたらごめんなさい...
今回の件で言うと、アプリケーションの本質とはあまり関係ないところ(ウィンドウの移動なりサイズ変更なり)に関してのギミックという気がするので、まあ、どうでもいいかなぁと思ったりもします。
ウィンドウの個別スケーリングについては賛成です。うちのオヤジはかなり老眼が進んでいるので、1280x1024 の液晶モニタで Illustrator を使う時、頂点のポイントが小さすぎて選択するのが辛くて欝になってます。なんで、そういう人にはいいかなぁと思いますね。液晶モニタだと、パリっとした解像度は決まってるので。
-- 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
Re:ダブルバッファリング (スコア:0)
>に描画するようになるらしいのが目玉なんだと思います
というより3D機能を使うわけだから。アプリケーションごとに仮想VRAMみたいなものを割り当てるのでしょう。
そしてハードウェアであるGPUが合成、表示を行うと。
今まではOSと各ソフトが画面を共有していましたが、これが各アプリケーションごとに分離されるわけです。
初期のリアルモード下で動くWindowsではメモリが共有されているような状態だったので
メモリの確保や解放にもWinAPIを使い、内容変更にもLock/Unlockをし
Re:ダブルバッファリング (スコア:0)
「The everything is the textured polygon」
ようするに、最近の3Dゲームの描画が速いのと
同じ理屈になるわけです。