当方VB6.0(sp6)、WinMeの環境にてプログラミングを行っています。
容量の大きな多数のビットマップデータを高速で保持(保存？)するため、メモリマップトファイルを作成し、そこにデバイスコンテキストを作成してBitbltで画像データをコピーすることはできないかと考え試行してみたのですが、メモリマップトファイルにデバイスコンテキストを作成するということ自体が的外れのように思えてきました。
そこで、メモリデバイスコンテキストに画像データをBitbltし、これをファイルマッピングできないかと考えました。
いくつかのサイトの記事を参考にさせていただき、メモリデバイスコンテキストを作成しこれに画像データをBitbltすることと、メモリマップトファイルを作成しこれに文字データを保持させる(コピーする？)ことはできたのですが、メモリデバイスコンテキスト内の画像データをファイルマッピングする方法を見出すことができません。
当方メモリ関連のプログラミングの知識が乏しい浅学ため、上記の方法そのものが的外れなものかどうかさえ判断できかねています。
メモリデバイスコンテキスト内の画像データをファイルマッピングする方法、もしくは上記の方法以外で大容量の多数の画像データを高速で保持(保存？)する方法をご存知の方がおられましたらご教示いただけないでしょうか。
長文となり恐縮ですが、よろしくお願いいたします。
API関数のCreateDIBSectionについて調べてください。
ただ、まぁ、個人的には、GDIベースで巨大なBitmapを保持するのは
お勧めしません。
保持するのであれば、今保持してるものをそのままに
しておけば、いつまでも保持してると思われるし、
保存したいのなら、メモリマップトファイルに書き込んで見ても
何も速くならないと思われるのだが。
K.J.Kさん、ねろさん、Resをありがとうございます。
To K.J.Kさん
CreateDIBSectionによってファイルマッピングされたDIBセクションを取得するこ
とができるのですね。
＜ただ、まぁ、個人的には、GDIベースで巨大なBitmapを保持するのはお勧めしま
せん。
これは、個々のビットデータを直接メモリ上に保持する方がより良い結果が得られ
るということでしょうか。
私も最初にその方法を考えたのですが、個々のビットデータとして保持するよりも
ビットマップデータとして保持する方が適切かと思い(何の根拠もなくただの思いつ
き)上記のような方法を採用しようとしたしだいです。
これからGetDIBits、SetDIBitsを使用して直接メモリ上に保持する方法を学習し、
上記の方法と比較してみようと思います。
To ねろさん
＜メモリマップトファイルに書き込んで見ても何も速くならないと思われるのだが。
物理メモリ領域に収まらない部分がシステムによって仮想メモリ領域に割り当てら
れるよりも、自発的にファイルマッピングしたほうが高速になるのではないかと考
えた(何の根拠もありません)のですが、HDにアクセスする限り速度的には変わらな
いということなのでしょうね。勘違いをしていたようです、ご指摘ありがとうござ
いました。
NT系ならばともかく、MeのGDIだと16bitsによる制限がいろいろと
出てきますよね。
で、構造をいろいろ模索してみては。メモリを食う複数のデータが
ある場合、そのうち、本当にメモリ上に置いておくべきデータは
全てなのか? ということもありますし、また、全てが非圧縮の
16bits、24bitsもしくは32bits DIBとして保持すべきか、などの
問題もありますし。