ダブルバッファリングによるビットマップ描画で – 固定ページ 2 – プログラミング – Home

ダブルバッファリングによるビットマップ...
 
通知
すべてクリア

ダブルバッファリングによるビットマップ描画で

固定ページ 2 / 2

WORLD
 WORLD
(@WORLD)
ゲスト
結合: 15年前
投稿: 8
Topic starter  

ソースコードです。覚えている範囲で^^;

メンバ変数
CDC m_backDC;

OnCreate()
{
CClientDC dc(this);
m_backDC.CreateCompatibleDC(&dc);
}

OnDraw(CDC *pDC)
{
CDC memDC;
HBITMAP hBMP;
BITMAP bmpWK;
CBitmap bmp;
CBitmap *pbmp;
CRect r;

GetClientRect(r);

bmp.CreateCompatibleBitmap(&m_backDC, r.Width(), r.Height());
pbmp = m_backDC.SelectObject(&bmp);

memDC.CreateCompatibleDC(pDC);
hBMP = CreateDIBSection();

memcpy(); // CreateDIBSection()で得られたビットマップ領域(?)にDIBをコピー

pbmp = memDC.SelectObject(hBMP);
GetObject(hBMP, sizeof(HBITMAP), &bmpWK);

m_backDC.StretchBlt(); // memDCからm_backDCに対してStretchBlt()

DelectObject(hBMP);
memDC.DeleteDC();

pDC->BitBlt(0, 0, r.Width(), r.Height(), &m_backDC, 0, 0, SRCCOPY); //m_backDC
からpDCに対してBitBlt()

m_backDC.SelectObject(pbmp);
}


返信引用
bun
 bun
(@bun)
ゲスト
結合: 24年前
投稿: 761
 

> 負荷が高いのは、私のコーディングもあるとは思いますが、カメラの数ではないかと
思っ
> ています。
それもあるかと思いますが、その前にやれることがあると思うから、
ここで質問しておられるのでは?
そうでないなら、話合い自体が無意味です。

これまでの情報からすると、
ちょっとした注意(テクニック)だけでも高速化できそうです。

すでに他の方も言っておられますが、OnDraw()の中で毎回やらなくていいことは、
あらかじめ終わらせておいて、OnDraw()では最低限のことだけをするのです。

ウィンドウサイズや配色などが変わらない限り、
CreateCompatibleDC()
CreateDIBSection()
などは1回やれば十分です。
他にもいろいろ高速化手法はありそうです。

もし、それらをやってもなお重いなら、本物の限界です。
静止画を連続転送して動画っぽく見せようとしているようですが、それだと非常に
重いです。大抵の動画フォーマットは動いている部分だけを送信し、背景部分は送
信しないのです。

ハードウェアMPEGエンコーダを内蔵したカメラ等に切り替えて、MPEG画像を表示す
るようにするとか、根本的な対策が必要でしょう。


返信引用
ryo
 ryo
(@ryo)
ゲスト
結合: 23年前
投稿: 252
 

○ソースについて
記憶を頼りにってことなので、細かくは書きませんが
これが本当なら、ビットマップとDCのselectobjectの関係や、
解放の順番などがおかしいです

タスクマネージャのGDIオブジェクトの数を確認してみてください

カメラを減らそうが、OnDrawが呼ばれる回数は変わらないはずだから
あまり関係ないかもしれませんが・・・


返信引用
PATIO
(@patio)
Famed Member
結合: 3年前
投稿: 2660
 

描画がおかしくなる件に関しては本来なら一旦閉じて
別のスレッドとしてあげても良い話だと思います。
話題が変わるならそのタイミングでスレッドを変えるようにしないと
同じスレッドが長くなりすぎますし。

実際に描画がおかしくなっている状態の時に転送先のRECTがどうなっているのか
確認するべきだと思います。
デバッグビルドでも動かせるなら普通にTRACEで出せると思います。
リリースビルドで無いと動かせないならOutputDebugStringを使って
デバックモニター系のソフト使うという手もあります。

実際の状況を捕まえない事には判断も出来ません。
実際の状況を捕まえる所からやって見てはどうでしょう。


返信引用
PATIO
(@patio)
Famed Member
結合: 3年前
投稿: 2660
 

基、

>実際に描画がおかしくなっている状態の時に転送先のRECTがどうなっているのか

実際に描画がおかしくなっている状態の時に転送先のサイズがどうなっているのか

とした方が状況に合いますね。


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

> やはり、負荷が高いのが有力のようですね。
> 負荷が高いのは、私のコーディングもあるとは思いますが、カメラの数ではないか
> と思っています。
> カメラの数を減らしたところ、発生しなくなりました。
> カメラの画像は、某メーカーから提供されているDLLのコールバック関数で取得して
> います。
> その関数はDLLからコールされるのですが、コールされる頻度はこちらで
> コントロールできないのです。
> カメラ1台でも数百ms間隔でコールされています。
1.データを保存するのに専念して、表示を間引きしたらどうですか?
  データ表示の終了のフラグをつけて、表示が終了するまで画面を再描画しない。
  表示できなかったデータは保存のみにして表示しない。

2.カメラの台数は何台ですか?
  顧客とカメラの最大数を取り決める。(固定にする。)
  MDIにして、カメラの台数分のウインドウを開く。
  それぞれスレッドにして描画に専念させる。

かな?
あと、僕も

ryoさんの意見で
 > ○ソースについて
 > 記憶を頼りにってことなので、細かくは書きませんが
 > これが本当なら、ビットマップとDCのselectobjectの関係や、
 > 解放の順番などがおかしいです

 > タスクマネージャのGDIオブジェクトの数を確認してみてください
これが気になりますね。
無視すると、数時間後にOS自体がリソース不足で暴走・停止する可能性があります。

 


返信引用
固定ページ 2 / 2

返信する

投稿者名

投稿者メールアドレス

タイトル *

プレビュー 0リビジョン 保存しました
共有:
タイトルとURLをコピーしました