C# と VB.NET の質問掲示板

わんくま同盟

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト


(過去ログ 16 を表示中)
■6220 / )  Re[6]: 画面切替をスムーズにしたい
□投稿者/ とっちゃん (178回)-(2007/08/06(Mon) 13:45:48)
とっちゃん さんの Web サイト
No6200 (れい さん) に返信

> 「GetMessageが呼ばれて且つメッセージキューが空の時」
> に戻ると思ってたんですが、
> そうではなく、
> 「GetMessageが呼ばれた時」
> に戻るのでしょうか?
>
もっと正確に書けば、メッセージキューに問い合わせが行われるタイミングで
(GetMessageだけでなく、PeekMessage や MsgWaitFor... などもあります)
WaitForInputIdle の待ちが解除状態になります。

で、その後適切なタイミング(要するにまってる側にCPU時間が割り当てられる)で
動き始めます。

現在のWin32 は、CPUが一つでもタイムスライスを小さくしているので
ほぼ並行して走ります。

なので、結果的にはGetMessage() が呼ばれた直後くらいのタイミングで
動き始めるという形になります。

ちなみに、メッセージキューができるのはもっと手前で、
CreateWindow されたタイミング(がほとんど)と言ってよいでしょう。

WaitForInputIdleは、キューが作られたじゃなくて、
キューに問い合わせに行けるようになった(=通常のメッセージループに入ったと解釈)
でもう待ってなくてもいいだろう!
という形で用意されています。

このあたりは昔の名残ですが、昔はアプリ起動時のウィンドウの作られ方が

CreateWindow();
ShowWindow();
UpdateWindow();

メッセージループへ
という流れだったことから考えれば至極当然ではないかと思われます。
.NET だからどうとかなんてのが考慮されるとすれば、もっとOSのそれも
かなり深い部分でテコ入れされない限りは無理でしょう。


> A画面.exeのメッセージキューが出来てから、
> メッセージループに入る前、なにかいろいろ初期化している間に
> WaitForInputIdleが呼ばれてしまっているので戻り値trueで即復帰するのかと思いましたが、
> 違うのかな?あってるのかな?
>
A画面exe はそれはそれで独自のプロセスであるというのも同期処理では重要です。
コンテキストの基本分割単位はプロセス単位ですので、優先順位の高い(アクティブな)プロセスに
より多くのCPU時間が割り当てられます。

また、待機状態になることで優先順位が下がるということもありません(これも重要)。
なので、どのタイミングで処理が走り始めるのか、いつ待機状態にするのか、などなど
結構微妙なタイミング調整は発生しえますよ。

極端な話、ウィンドウがあっても見えないままいろいろやってるソフトもありますし
ウィンドウを作る前にいろいろやるものもある。

返信 編集キー/


管理者用

- Child Tree -