PixelFormatの速度が機種依存する?

解決


よしたけ  2009-11-27 03:59:02  No: 36274

DELPHIでのプログラム開発に関わり始めた者です。よろしくお願いします。

BitmapのPixelFormatの動作が機種に寄って10倍以上違いが発生します。
例えば、Bitmap.PixelFormat := pf24bit;なる様な構文が15行くらい続く箇所があるのですが、ビルド後同一の実行ファイルをDELL T390やT3400等で実行させると該当するプログラム部分を数秒で通過し初期画面が表示されます。しかし、T3500で同じ事をすると、該当部分を通過するのに数十秒要します。
その後のプログラム動作に速度差は感じません。

DEPHIは7です。

CPU側の問題でしょか?

PixelFormを用いないで、":= pf24bit"と同等の処理が可能でしょうか?

まったく別の要因でしょうか?


よしたけ  2009-11-27 04:04:30  No: 36275

失礼しました。

”PixelFormを用いないで、”は”PixelFormatを用いないで、”
の誤りでした。


monaa  2009-11-27 07:35:53  No: 36276

これは一つずつ問題を解決していかないとわからないと思います。
開いてるビットマップファイルはどれも同じですか?
あと、現象を再現できる最小限のソースを作るというのが面倒でも最も解決に近付く近道です。
案外、意外な場所にバグがあったりします。

>PixelFormを用いないで、":= pf24bit"と同等の処理が可能でしょうか?
可能ですが最低限Bitmap構造体を理解する必要があります。


よしたけ  2009-11-27 18:32:22  No: 36277

そうですね。
やはり一つずつ可能性をつぶして行くほかありませんか。
まだ、DELPHIプログラミングは初心者なので、ハード的な面から検討します。
ハードディスクからのプログラムローディング、メモリー確保や画像処理関係が影響しているのでグラフィックドライバー等が疑っています。

因みに、開いているBitMapは全て異なります。

ただ、PixelFormatが機種依存して実行速度を著しく低下させる様な処理をしているのでしょうか?
ただ、画像フォーマットを規定しているだけのような気がします。


よしたけ  2009-11-27 20:35:30  No: 36278

ハード的に少し分かった事は、HDDの速度は関係ないようです。
メインメモリの領域確保は元々見当違いだった様で検討から除外。

問題は、グラフィックドライバーです。
速度に問題が無いT390等では、グラフィックドライバーの影響は無くグラフィックドライバーを外しシステム標準のVGAドライバーでも速度は同じです。もちろん描画速度は遅くなります。
一方で、速度に問題があるT3500ではグラフィックドライバーを組み込んでいると極端に遅いですが、外してVGAドライバーに変更するとT390等と同等の速度になります。(もちろん描画は遅いです)

これらは何を意味するのでしょう?

PixelFormatの処理はグラフィックドライバーの影響を受けるのでしょうか?
T340等では速度にグラフィックドライバーの有無による影響はありません。不思議です。

グラフィックドライバーはシステムに付属の物で特に変更などしていません。
両者は共に"nVidia Quodtra"を搭載していますが、ドライバーは全く同じではないとは思いますが、同一メーカーの同一シリーズです。

合理的解釈は成り立つのでしょうか?


monaa  2009-11-27 20:44:23  No: 36279

PixcelFormatはBitmapのフォーマットが元と違う場合に新しいBitmapを再構築します。
Bitmap構造体はフォーマットを変えたい場合、再構築以外の手段はありません。
今回だと元のBitmapが24bitだと何もしていません。
ちなみにBitmap関連の大抵のAPIは昔ならまだしも、
今時期の環境ではまずグラフィックカードに依存することはありません。
(Windowsのカラー値が32bitの場合)
多少はCPU依存はあるかもですが、それも微々たる差だと思われます。
それにこれだけ使われてるTBitmapに重大なバグがあるとはとても考えづらいです。
多分、ファイルのロード時間だと思いますよ。


monaa  2009-11-27 20:48:35  No: 36280

あら、アクセラレータ関連ですか。
私も以前、BitBltを多様したときアクセラレータの設定で不思議な現象に出会った事があります。
できれば、現象の再現できる最小コードが欲しいところです。
今は時間が無いのでまたあとで。


よしたけ  2009-11-27 22:33:55  No: 36281

ありがとうございます。
お時間のある時で結構ですので、ご意見下さい。

当初、ご指摘にある様にファイルのロードの問題と思われHDDを疑ったのですが、同じハードディスクをSTATとPATAとI/Fを選択できるものがあったのでそれで試しましたが顕著な相違が現れませんでした。
ただ、確かに、プログラムが停止している様な状態の時HDDのアクセスランプは点滅します。
ここでグラフィックドライバーをアンインストールして試すと顕著な影響を確認できた為、HDDの問題ではないと判断しました。

アクセラレータの問題として、コードも見て頂きたいとは思いますが、
実は開発し始めたものではなく、既存のプログラムのメンテ(修正)をはじめたところです。
ですので、膨大なソースなので最小のコードがどの程度なのかまだ判断つきません。ついたら自ら解決できるのでしょうか?

制作者もPixelFormatが時間のかかる処理とは思えず、ドライバーの影響も半信半疑です。

ただ、ファイルのロードの問題だったとしても、それがグラフックドライバーの組み合わせとどう関係するのでしょうか?

自分の解釈では釈然としない検証結果で理解に苦しんでいます。


monaa  2009-11-28 05:50:51  No: 36282

昔の経験をたどっていろいろ調べましたが、
一部のハードウェアアクセラレータはBitBlt処理が激重になるみたいです。
今の私の環境ではそれを再現するビデオカードがないのでBitmapのどのフォーマットが処理を重くするのかはわかりません。
ぶっちゃけビデオカードのバグとしか言いようがありませんが、すべての処理をCPUに委託するにはアクセラレータをOFFにするしかありません。

今の高速描画はDirectXが主流ですが、
昔の2D高速描画はハードウエアアクセラレータで描画系のAPIを高速にすることがありました。その一部の環境のバグみたいですね。
私はBitBltで発生しましたが、Bitmap関連で他にも色々問題があるのかと思われます。
結論から言いますと、バグだから仕方なし。
です。
ちなみにpixcelformatの変更だったらAPIを使わずに自前でできないわけではありません。でもめんどくさいです。

http://74.125.153.132/search?q=cache:85oy1C6PMuAJ:bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi%3Flog%3D3%26vew%3D598+hardware+acceleration+bitblt&cd=5&hl=ja&ct=clnk&gl=jp&lr=lang_ja
http://saya.s145.xrea.com/archives/2006/06/poweredge_sc430_3.html
http://www.eggheadcafe.com/software/aspnet/33811985/bitblt-slow-on-some-hardw.aspx
http://www.gamedev.net/community/forums/topic.asp?topic_id=226276


monaa  2009-11-28 05:55:13  No: 36283

いちばん上リンク間違えました。
http://74.125.153.132/search?q=cache:9xVUCV7N7KoJ:bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi%3Flog%3D43%26vew%3D324+%E3%83%8F%E3%83%BC%E3%83%89%E3%82%A6%E3%82%A7%E3%82%A2+%E3%82%A2%E3%82%AF%E3%82%BB%E3%83%A9%E3%83%AC%E3%83%BC%E3%82%BF+BitBlt&cd=3&hl=ja&ct=clnk&gl=jp&lr=lang_ja


KHE00221  2009-11-28 12:34:24  No: 36284

とりあえずグラフィックドライバーを更新するのが先じゃないのか?


よしたけ  2009-11-28 17:58:34  No: 36285

取りあえずグラフィックボード毎交換してみてどうか、と言う方向で進んでいます。


KHE00221  2009-11-29 23:17:18  No: 36286

よくわからんけど
グラフィックアクセラレータってのはVRAMではなくメモリ上に作った
BMPでも利くものなの?


monaa  2009-11-30 00:36:16  No: 36287

正式な文章は見つけることができませんでしたが、
WindowsXPのハードウェアアクセラレータは
APIを丸々置換してしまうようなことをちらほら見ました。
DirectX技術とは違ったグラフィックカードの使い方をしているようです。
またWindows7になってからDirectXに組み込む形で様式が変わったみたいです。(Direct2D)
http://msdn.microsoft.com/ja-jp/windows/dd647497.aspx


monaa  2009-11-30 00:40:32  No: 36288

文章が変なので修正。
>またWindows7になってからDirectXに組み込む形で様式が変わったみたいです。(Direct2D)
>http://msdn.microsoft.com/ja-jp/windows/dd647497.aspx
これはハードウェアアクセラレータの新機能じゃなくて
Windows7で高速2D描画を行う新API群です。


よしたけ  2009-12-01 22:38:02  No: 36289

少し間が開いてしまい、失礼いたしました。

貴重な情報をありがとうございます。

グラフィックボード(とドライバー)を交換してみました。
正常な速度で起動するT390のグラフィックボードをT3500へ組み込むと正常な速度で起動します。

両グラフィックボード共に、NVIDIA Quadroシリーズでほぼ同じ仕様ですが、最も異なる点はディスプレイモニターへのI/Fです。
T390用のものは"DVI"で、T3500用のものは"Didslay port"で変換アダプターでVGAにしています。
詳細は分かりませんが、DELLによりますと"Display port"の採用でドライバー仕様が変わっているそうです。
この辺りの影響でしょうか?
ソフト的にはこれまで一切起動時の問題は生じていなかったので、ソフトウェアの改修の必要性は今のところ感じていません。

グラフィックボードをDVI I/Fに交換する他に対応はない様ですね。いかがでしょう?


よしたけ  2009-12-03 20:56:16  No: 36290

続報です。

市販のグラフィックボード&ドライバーで試してみました。

1)ATI Radeon HD4350 - I/F VGA, DVI-I, HDMI
2)nVIDIA GeForce8400GS - I/F VGA, DVI-I, HDMI

です。
1)2)共にVGA. DVI-Iいずれでも、問題のソフトの起動に遅延はみられません。

ちなみに、DisplayPortとHDMIはコネクター形状が酷似していますが、互換性はありません(差さりません)でした。
HDMIでDiplayPortの検証が出来ると思ったのですが、私の勘違いです。

T3500のグラフィックドライバー(nVIDIA QUADRO NVS 295 - DisplayPort)のバグという結論に行き着くと思います。


よしたけ  2009-12-06 02:03:56  No: 36291

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

対処療法的ですが、取り敢えず問題は回避できました。

また、何かの際はよろしくお願いします。


※返信する前に利用規約をご確認ください。

※Google reCAPTCHA認証からCloudflare Turnstile認証へ変更しました。






  このエントリーをはてなブックマークに追加