回答 1: 描画できないのはメモリが不足しているため。ゆえに環境依存。
　　　　試しに、元画像2400*1300でm_zoom=15倍とかの大きさのビットマップを
　　　　CreateCompatibleBitmap() してみるとよろし。戻り値はおそらく FALSE に
　　　　なるでしょう。

回答 2: その手法でよろしいかと。

DDB(普通の意味でのビットマップ)は印刷のことも含めて考えると
使わない方がいいですし、あまり大きなビットマップが作れない
場合もありました
（もっとも、これは１０年以上前の経験からのことなので今は改善しているかも
しれません）

DIB か DIBセクションかなら DDB 程の制限は経験しませんでしたが、
当時は１Ｇバイトもの大きさの画像データーを扱うこと自体が特殊
な時代でしたから（そもそも身近にそんなに大きな画像データーが
なかったし、8 ビットカラーが当たり前の時代でしたので 24bitカラー
や 32bit カラーのデーターがあっても使えるグラフィックカードが
8bit カラーしか扱えないといった時代でした）

ところで色深度について（３２ビットカラーとか１６ビットカラーとか
８ビットカラーとか）触れていないので、画像データーの大きさ（
バイト数）が判りませんが、 XP が扱えるユーザー領域の制限以内に
収まることは間違いないのですね？
（一つのアプリケーション全体で２Ｇバイトより１Ｍバイト少ない）

FlatWest様、しま様　ご回答ありがとうございます。

色深度についてですが32bitを使用しているので15倍では2Gバイトを超えていました。
これが原因のようですね。

>試しに、元画像2400*1300でm_zoom=15倍とかの大きさのビットマップを
>CreateCompatibleBitmap() してみるとよろし。戻り値はおそらく FALSE に
>なるでしょう。

確かにFALSEが返ってきました。2G以下でもFALSEが返ってきます。
DDBは大きなビットマップを扱えないようですね。

疑問が解決してすっきりしました。
早速修正の作業に取り掛かります。

ありがとうございました。

すみません、解決欄のチェックをし忘れました。

CreateDIBSectionのhSection引数(handle to a file mapping object)を使えば
大きなビットマップを作れそうです。

1)(2400 * 15) * (1300 * 15) * 4 = 2.8GByte以上の file mapping objectを作る
2)転送先をY軸方向で分割して細長いDIBSectionを作り、ビットマップビットを書き込む
　つまり、CreateDIBSectionのBITMAPINFOHEADERのbiHeightを 1/nに、
　dwOffset size * i / nにして、ループしながらビットを書き込んでいく
3)描画時は、画面高さのDIBSectionを作る
4)file mapping objectは終了時まで保持する

こんな流れです。

# file mapping objectを丸ごと使ったDIBSectionは失敗しました。
# 私の環境ではCreateFileMappingのhFile引数を0xffffffffにすると
　スワップが始まって大変でしたが、描画は早いようです。
# 速度が実用的かどうかは分かりません。

もういっちょアドバイスすると、StretchDIBits()の「コピー先・・・」は
せいぜい対象Viewの大きさ程度で十分ですね。デスクトップサイズにしてる
コードも見かけますが、マルチモニター時に破綻します。
また、それに対応する元画像の「コピー元・・・」は「コピー先・・・」サイズ
から勘案して、小さくできるわけです。そうすると
　m_SizeX * m_zoom
の様なややなげやりなコードにはなりません(笑)。
もちろんdoubleで計算して、四捨五入などの誤差まるめを行ってください。

まだ、工夫の余地があるようですね。

> 3)描画時は、画面高さのDIBSectionを作る
「画面」は方言ですねw。描画先のウィンドウのクライアントエリアの高さです。

> また、それに対応する元画像の「コピー元・・・」は「コピー先・・・」サイズ
> から勘案して、小さくできるわけです。
これは異論あり。元画像が実寸(たとえば[mm]単位)の可能性もあります。

前回書き漏れたこと
CreateDIBSectionのdwOffset引数の下位2bitはゼロにしないとまずいようです。
(こういうのは何と書けばいいのか、要はDWORD単位ということです)

> これは異論あり。元画像が実寸(たとえば[mm]単位)の可能性もあります。

若干誤解されたかもしれませんね。詳しく解説すると、拡大を

(1)拡大した全幅(Xz) = 元BMPの全幅(X)　×　拡大率(Z)

の様に定義し、Viewの実際の幅を(Xv)とするならば、

(2)Xz = X * Z より Xv = Xpart * Zが導かれます。

つまり、Viewの幅全てにZで拡大したBMPを表示するときに
必要になる元のBMPの幅(Xpart)は

(3)Xpart = Xv / Z

で求められます。つまり以降の(4)と(5)は数学的に等価ですが
中間で算定される数値が小さいため、(5)の方が
「早く」「少ないメモリ」で動作するわけです。

(4)　StretchDIBit(
　　hdc_ura,
0, // コピー先長方形の左上隅の x 座標
0, // コピー先長方形の左上隅の y 座標
(現画像の幅) * Z, // コピー先長方形の幅
(現画像の高) * Z, // コピー先長方形の高さ
0, // コピー元長方形の左上隅の x 座標
0, // コピー元長方形の左上隅の x 座標
(現画像の幅), // コピー元長方形の幅
(現画像の幅), // コピー元長方形の高さ
・・・);

(5)　StretchDIBit(
　　hdc_ura,
0, // コピー先長方形の左上隅の x 座標
0, // コピー先長方形の左上隅の y 座標
(Viewの幅), // コピー先長方形の幅
(Viewの高), // コピー先長方形の高さ
0, // コピー元長方形の左上隅の x 座標
0, // コピー元長方形の左上隅の x 座標
(Viewの幅) / Z, // コピー元長方形の幅
(Viewの高) / Z, // コピー元長方形の高さ
・・・);

いかがでしょう。
もちろん細かい例外が必要ですが。

> で求められます。つまり以降の(4)と(5)は数学的に等価ですが

違いますね(笑)。

で求められます。つまり以降の(4)と(5)は表示上は同等の結果になりますが

に訂正します。

スクロールでページup/downする毎に
元ビットマップから拡大ビットマップを作り直すという理解で良いですか。

もしそうならば、どっちが使い勝手がいいんでしょうか。
私の方法では読み込み時に時間がかかります。
スクロールは早いんじゃないかなぁと期待していますが、
多くの場合、実験は期待を裏切りますからなんともいえません。

>スクロールでページup/downする毎に
>元ビットマップから拡大ビットマップを作り直すという理解で良いですか。

そうですね。
表示のみ(含む拡大縮小オフセット)やトリミング程度の編集を目的とした場合は
　１．編集対象全体(又は部分)を選択した裏DC
　２．表DC
の２段式でも十分かもしれませんが、より複雑な画像処理の場合は

　１．編集対象全体を選択しているDC
　２．インターフェース専用DC(拡大縮小、オフセット、他)
　３．表DC

の少なくとも３段式になると思います。この場合

　(１)ラバーバンド、編集用ハンドル、等は２．又は３．へ描画
　(２)編集操作確定後の描画処理は当然１．へ描画

みたいな感じ。
実際には効率を上げるため、さらに複雑になってると思われます。
要は２．の表示インターフェースDCの仕組みを工夫して、
いかに早く、効率的に表示して見せるかにかかっていると思われます。