こんにちは、川合です。 I.Tak. さんは 2003/10/30 12:58:16 の「[OSASK 6620] VGA fast 32bp p putbox」で書きました： > VGAの32bppブロック転送タイリングつき (putbox) をかなり高速化 >してみました。予想以上のデキに嬉しくなったのでスナップ上げ。 >http://user.ecc.u-tokyo.ac.jp/~g240845/osask/lzh/osa411at.lzh あの手抜きルーチンを直してもらえたみたいでうれしいです。僕もか なり前から描画部分をputboxと同じアルゴリズムになるように改良しよ うと思っていたのですが、I.Tak.さんがやってくれたのなら、多分僕が やるよりも速いと思うので大いに助かります。 > ところで今回↑の方法で負荷を測ったところ, 「ウィンドウ移動の >とき, 灰色のウィンドウは全て常に再描画されている」という問題(?) >に気づきました。昔から無駄な再描画が多いと思ってはいましたが, >これで具体的に症状を特定できたようなのでこれも調べてみます。 これはまあ、問題といえば問題ですが、修正するにはやや大掛かりな 改造が必要です。 今のwinmanのウィンドウ移動アルゴリズムでは、ウィンドウ移動モー ドに入るに当たって、画面上の全てのウィンドウに対して、描画禁止シ グナルを送ります。・・・なんでこんなことをするのかというと、グラ フィックドライバの描画ルーチンはマウスとの衝突判定しかしていない ので、ウィンドウを動かすときに出てくる白い枠と描画が競合すると、 画面が乱れるからです。これを回避するために、描画が止まるわけです （Win95を観察していたらそういう風になっていたので、真似してみた というのもあります。楽そうだったので）。 そして移動先が確定したら描画禁止を解除するのですが、この場合、 描画禁止中に描画できなかった分を画面に反映させるために、再描画シ グナルを送ってやらなければいけません。そうなると、今のような動作 になります。 これを打開する方法は2つあります。 一つは、ウィンドウ移動モードでも描画を停止させないことです。こ れをやるには描画ルーチンの衝突判定ルーチンを改造しなければいけま せんが、それができると、ウィンドウ移動中も表示が止まらないので非 常にかっこいいです。 もう一つは、とりあえず停止はさせるが、差分再描画シグナルを送っ てやることです。これだと、描画禁止期間中に更新のなかったテキスト ボックスやグラフィックボックスについては、再描画を抑制できます。 ただしpioneerを差分再描画に対応させないと、効果はありません。結 構しんどそうです。 それでは。 -- 川合 秀実(KAWAI Hidemi) OSASK計画代表 / システム設計開発担当 E-mail:kawai !Atmark! imasy.org Homepage http://www.imasy.org/~kawai/