🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: japan.comp.lang.delphi
Article #6

Re: 画面モード切替後のグラフィックパフォーマンスの低下

#6
From: HIRAO
Date: Sun, 26 Dec 1999 00:00
109 lines
6259 bytes
林 知紀 wrote in message <83u3iq$i92$1@nw041.infoweb.ne.jp>...
>フォローありがとうございます。
>
>原因というか元凶が判明しました。
>Image1.Refresh
>のコードを実行するのに異常に時間がかかるようです。
>結局 TForm.Canvas に直接描画する形をとり、
>パフォーマンスの低下を防ぐことが出来ました。

 僕はC++Builderのユーザですが途中からおじゃまさせていただきます。
VCLは同じだと思いますので・・・

 そう言う方法で問題が発生しないと言うことは、TImageの中のバッファ
用のビットマップのデバイスコンテキストと画面のデバイスコンテキスト
が合っていないから、変換に時間がかかっているのではないでしょうか?
(ソースが付いていましたらデバッガーで追いかけてみると良いかも、
せっかくパスカルのソース読めるのですからもったいないですよ(^^;;)

 TImageの中にはバッファ用のビットマップが自動的に作られますので、
それを画面モード切替後に消去して作り直せばいけるかもしれません。

 PictureプロパティーのTPictureオブジェクトを解放してみてはどうでしょうか?
それでもだめでしたら、TImage自体を動的生成するようにしてみるとか…

>でも TImage を使うことをまるっきり諦めなければならないので
>汎用性やプログラムの構築に関する生産性が悪くなりそうです。
>まあどちらにせよほとんどTBitmapで表示するための画像を作成してるので
>僕自身は大して困らなさそうです。

 バッファリングをしないあるいは自分でするのでしたら、
TPaintBoxが使えるかも…

 MLとかの方がニュースより情報が豊富かも知れません。
http://www2.big.or.jp/~osamu/Delphi/index.html
ここから両MLへ行けます。

>多分 TImage オブジェクトのバグみたいなものなのかと思います。
>Delphi5だとこのあたりはどうなってるのでしょうか?
>改善されてるのなら乗り換えたい気持ちもあります。

 そもそもWin32APIでそう言うことをするための仕組みって用意されて
いないのではないかな… アプリケーションで勝手に画面モード変えち
ゃうといろいろ副作用出ませんか? 僕の知っている方法ではディスク
トップ上のアイコンの位置が変わる、開いているウインドウのサイズが
変わる等いろいろ副作用がありましたので、そう言うことはアプリケー
ションはユーザーに指示を出すだけで画面モードの選択はユーザーに任
せるのが基本ではないかと… つまり画面モードが替わったことをアプ
リケーションに知らせる仕組みも用意されていないのではないかと…
アプリケーションの側が抜けているんでしょうか? だとすればメッセ
ージを拾ってプログラマーがそう言うプログラムを組めば解決できますね。
(もちろんバージョンアップで対応されると良いと思いますが、
今現在もVCLはいろいろ自動化されていてそう言う抜けがあるわけで…)

>> Windowsの描画は、DC(デバイスコンテキスト)を使って
>> 行われるのが普通です。
>> Delphiからでも、DC関連のAPIは直接操作できますので
>> Cを無理に使う必要はありません。 
>
>APIを使うと2~3倍くらい早くなるような感じがしますが
>目にもとまらぬ速さで結局ウェイトを入れるので意味なしでした。
>APIを直接操作することになれていないので
>Delphiのコードを使うことにします。

 そのVCLの自動化の部分がオーバーヘッドになりますから、
小さいビットマップをたくさん扱ったりとかの処理だと確かに差が
出ますね… でも大きいビットマップの場合はそれ自体のデーター
転送に時間がかかりますので差が全然出ませんでした。
 場合によっては遅いかもしれませんが、いろいろ自動化されているのは
魅力的ですよね。MFC何かは素のAPIに近いみたいですから面倒くさそう
ですよ…
(将来はlunix版なんかも出るらしいですし… そうなればマイナーから
一気にグローバルですし(^^;;)

>Delphi4についていたMicrosoft SDKヘルプファイルを見ながら
>試してみたのですが、
>引数とかが全部Cの型で書かれていて焦りましたが
>(しかも全部英語。専門用語って難しいです。
>雰囲気で読み飛ばすしかなかった)
>実際の入力の時には入力補助がPascalの変数の型で表示されたので
>案ずるより生むが易しといった感じでした。

 その辺の入力補助ですが、C++Builderの場合は遅くてつらい物が
あります(T-T;; C++言語も超ややこしいですし…

>> でも今は、C++を使っています。
>> 直接の理由は、DirectXのPascal用のヘッダーを手に入れる
>> のが難しかったからですが、その他にも「ほとんどの解説書が
>> C++を前提にして書かれている」からです。

 サンプルがC系で書かれているというのは強力な理由になりますよね…
ただC++もダイエットが必要ではないかと思う…

>そうですね。
>でもポインタとかを操作するとよく飛んでいってしまうので
>できればC++に移行したくないんです。
>それと文字列の操作が面倒くさそうなのが難点です。

 C++なら標準C++ライブラリーと言うのがあって
文字列ならstring型がVCLのAnsiStringと同じように使えますし、
そのほか、リストも有りますし当然こちらの方が機能は上でしょう、
連想配列とかVCLにはないようないろいろ強力な物が有りますので
VCLよりそう言うのを使うようにした方がいいかもしれませんね…

 ただC++は、ポインターとかテンプレートとかややこしい物が
いっぱいですね(^^;;


平生 ゆう
hirao@dog.net0726.or.jp
Technical Details
Message-ID: <842u63$fpk@www.net0726.or.jp>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <83ou3d$jvv$1@nw041.infoweb.ne.jp> <3860CAFB.E16988D7@po.teleway.ne.jp> <83u3iq$i92$1@nw041.infoweb.ne.jp>

Show Full Headers
Complete Article Headers
X-Google-Language: Japanese,JIS
X-Google-Thread: 110a07,f2bd283c630b1b34
X-Google-Attributes: gid110a07,public
X-Google-Thread: feb2e,f2bd283c630b1b34
X-Google-Attributes: gidfeb2e,public
X-Google-Thread: fecfa,f2bd283c630b1b34
X-Google-Attributes: gidfecfa,public
From: "HIRAO" <hirao@dog.net0726.or.jp>
Subject: Re: 画面モード切替後のグラフィックパフォーマンスの低下
Date: 1999/12/26
Message-ID: <842u63$fpk@www.net0726.or.jp>
X-Deja-AN: 564811987
Content-Transfer-Encoding: 7bit
References: <83ou3d$jvv$1@nw041.infoweb.ne.jp> <3860CAFB.E16988D7@po.teleway.ne.jp> <83u3iq$i92$1@nw041.infoweb.ne.jp>
Content-Type: text/plain; charset="iso-2022-jp"
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Organization: NET0726
Mime-Version: 1.0
Newsgroups: japan.comp.lang.delphi,fj.comp.lang.pascal,fj.os.ms-windows.programming