アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
画面が3D化しても (スコア:1)
今のままだとあまり便利にはならないでしょうね。
とはいえ、画面の描画に今までの遅かったGDIではなく、
ゲーム用に高速化されている（高速化されていく）
DirectXベースの描画になるという点については、
少しは期待してよいのではないかと思います。
Re:画面が3D化しても (スコア:0)
やっぱ使いやすいかどうかより、見た目がすごいかどうかが重要だろう。Windowsの場合。
Re:画面が3D化しても (スコア:0)
> ゲーム用に高速化されている（高速化されていく）
> DirectXベースの描画になるという点については、
> 少しは期待してよいのではないかと思います。
素朴な疑問なのですが、DirectXベ
Re:画面が3D化しても (スコア:1)
「ＧＤＩクソだぜ！俺たちが作ったらこうなるんだ！イェーイ！！」
という理由で作られたからです。
これではあまりにひどいので、普通に書くと
あまりに煩雑化した階層構造を経由して描画するＧＤＩとは異なり、
グラフィックドライバーに直接命令するイメージに近い形を実現しようと
しているから、ＧＤＩに比べて高速であると思われる。
という感じでどうでしょうか？（誰に聞いてるんだか…）
ちなみに僕はWebブラウザの文字の描画がどのように行われているか
分からないので、その例に関してはお答えしかねます。
以下、長いので面倒なら読まなくてもいいです。
描画処理を行うときに、どのタイミングで画面の再構築を行うかという
ことで、ＧＤＩを利用する限り、ひとかたまりの文字列を画面に描画する
ごとに描画メッセージが発生して、画面が必要量だけ更新されます。
DirectXはゲーム用なので、恐らくですが、フレーム単位でしか描画命令が
発生しません。その理由は、通常、ゲームを作成する場合はフレームバッファに
対して描画を行い、垂直同期のタイミングに併せてフレームバッファから実際の
ディスプレイバッファにビット情報を転送するからで、その代わりに画面全体を
毎フレーム更新することになります。
文字を１文字画面に表示するには、ＧＤＩのように必要な範囲の更新のみを
行うと高速に処理ができますが、マルチタスクで色んな場所が一斉に更新される
／大量の文字を画面に描画しようとすると、画面の更新は一度に行った方が
速くなると予測されます。
こんなもんで納得いただけましたでしょうか？
なるほど (スコア:1)
ずいぶんご丁寧に書き込みですね。
久しぶりに感動してます（いや、マジで）。
私もこういう風に書き込みたいものだ。
（反省モード）
Re:画面が3D化しても (スコア:0)
> グラフィックドライバーに直接命令するイメージに近い形を実現しようと
> しているから、ＧＤＩに比べて高速であると思われる。
おお！
イメージがつかめました。
ところで…
> マルチタスクで色んな場所が一斉に更新される
> ／大量の文字を画面に描画しようとすると、画面の更新は一度に行った方が
> 速くなると予測されます。
ここが分かりません。
マルチタス
Re:画面が3D化しても (スコア:1)
GPU叩く際に発生するオーバヘッドは作業量の増減にあまり左右されません。また、垂直同期間隔より短い更新を繰り替えしても、無駄なわけです。
# rm -rf ./.
Re:画面が3D化しても (スコア:1)
でも、残念ながら同じと思っているのが間違いなのです。
実際にＧＤＩではどう処理するかと言うと、
１．更新すべき場所のメモリ空間を別のバッファに退避する
２．退避したエリアを初期化する
３．問題の場所に必要なデータを描画する
４．１に戻る
となっているようです。
だから、処理落ちしたウィンドウの部分が灰色に抜けたりすると思います。
で、これが複数のウィンドウからガンガン更新要求がかかるわけで、
１－４のループががんがん発生するわけです。
DirectXを使うと、
１．画面用バッファの初期化
２．文字の描画
３．すべての文字を描画するまで２を行う
４．垂直同期の時間がきたら画面用バッファからメモリへのデータ転送
となります。
つまり、１文字書いても２５６文字書いても同じだけの初期化処理で済むのです。
単純に１命令１回の時間を消費するとして、100文字の描画をしたとすると、
処理が必要な量は
GDI:
文字の描画範囲を別のバッファに退避：１００回
文字の描画範囲の初期化：１００回
文字の描画：１００回
合計：３００回
DiretX:
画面バッファ全体の初期化：１回
文字の描画：１００回
画面バッファから画面へのメモリ転送：１回
合計１０２回
これだけ処理すべき量が減ります。
これが分かると、「PS2ってWindowsなんかよりハイスペックだよね」
などというハズカシイ発言をしなくて済むようになります。
Re:画面が3D化しても (スコア:0)
＞実際にＧＤＩではどう処理するかと言うと、
＞１．更新すべき場所のメモリ空間を別のバッファに退避する
＞２．退避したエリアを初期化する
＞３．問題の場所に必要なデータを描画する
＞４．１に戻る
＞となっているようです。
これはUSER(32)の範疇であって、GDIはぜんぜん関係ないと思うんですけれど。
Re:画面が3D化しても (スコア:1)
正確には、ＵＳＥＲ３２（窓）の中でＧＤＩの描画オブジェクト
（線とか円とか）が存在して、その範囲内に描画を行う、でしたかね？
でも、ＧＤＩ使う＝ＵＳＥＲ３２も使うだと認識していますので、
全く関係ないとも言い切れないと思います。
で、１ですが、マルチウィンドウの基礎的な処理として、一応やってると思って
たんですが、Windowsってやってないんですね、すんませんでした。
２に関しては、背景消去（前景も消す？）のつもりで書いてます。
再描画要求の構造体の初期化は、もしあったとしたら完全に記憶からとんでます。
所詮は数日で得た知識。未熟者がでしゃばりすぎました。
Re:画面が3D化しても (スコア:0)
そもそも現在のWindowsの描画方法は、昔の貧弱な描画能力を前提としている部分も多々あると思いますので、
古い方
Re:画面が3D化しても (スコア:0)
をしていたのが、見えるもんは全部テクスチャードポリゴンにして
CPUはおおざっぱな作業しかしなくてよくなったから、CPUの負荷が
へるってことだろう。
Re:画面が3D化しても (スコア:0)
たぶん (スコア:1)
Re:画面が3D化しても (スコア:0)
>高速になる要因として何が挙げられますか？
Safari を使う