安達です。 初めての投稿かな?
暇だったので、Windows2000の上でテストしてみました。

Windowをぐりぐり動かすだけで、すべてのWindowMessageはDefWindowProc()で処
理しています。
ログはWM_SIZE, WM_SIZING, WM_PAINT, WM_NCPAINT, WM_ERASEBKGNDを取りまし
た。

「ドラッグ中に云々」 off
ドラッグ中はWM_SIZINGがモリモリ
終了後に WM_NCPAINT -> WM_ERASEBKGND -> WM_SIZE -> WM_PAINT

「ドラッグ中に云々」 on
ドラッグ中は WM_SIZING+ -> WM_NCPAINT -> WM_ERASEBKGND -> WM_SIZE ->
WM_PAINT
終了後になぜかWM_SIZING

小さく変更する時も、大きく変更する時も挙動は変わらないように見えました。

大方予想通りですね。
WM_ERASEBKGNDがWM_SIZEの前に来るのは知りませんでした。
以上に間違いがありましたら、是非教えてください。


僕としても、現状で明らかに「遅い」ならば、WM_SIZEでフラグを立てて、
WM_PAINTで作り直す案を推薦します。
富豪的プグラミングは「ユーザーフレンドリな事を最優先しろ」って話だと思う
ので、軽い方が使いやすいならばそちらを採用すべきです。
#1 「ドラッグ中に云々」も富豪的UIだよね
#2 上記案で作り直しても、見た目は変わらない「はず」

> 一般に描画やその前準備は WM_PAINT で行われるものです。だから、デバイス
> コンテキストは WM_PAINT にしか渡されません。WM_PAINT がくるまで、
> 描画対象がモニタ画面か、印刷か、画面での印刷プレビューか、
> あるいは EMF(メタファイル)への出力か、特定できないからです。
WM_PAINTは "paint a portion of an application's window" とMSDNに書いてあ
るので、WM_PAINTは画面への描画だと限定しても特に差し支えないと、僕は考え
ます。

んで、その他のデバイスコンテキストに出力する場合はWM_PRINTとかを使え、と
書いてありますね。僕はこのメッセージ処理したことが無いんであまり大きな事
言えませんが。



余計なお世話かもしれませんが、議論するのは結構ですが、本質に関係の無い所
で熱くならないようにしてください。
# 送信する前にいっぱいコーヒーでも飲むとか
VCPPは参加者数も多いですし、それに前にも似たような事があって後味の悪い結
果になったような気がするので

以上、乱文失礼しました。

/****************************************
 Shin Adachi
   s...@adachin.com
   http://www.adachin.com
****************************************/