- PR -

コンテナ画像の手前のコントロール描画について

投稿者投稿内容
udon
会議室デビュー日: 2007/07/15
投稿数: 13
投稿日時: 2007-07-24 20:00
れいさん、Jittaさん 返信ありがとうございます。
私の返信が遅く申し訳ありません。

返信しなかった間、エンドユーザに.Netを使わない開発方針を勧めていました。
回答はまだ頂いていないですが、個人的にはMFCでの開発で考えています。

引用:

引用:

画面のあるアプリケーションをすべて終了し、Windows エクスプローラを一枚表示します。これをつかんで、マウスを左右に激しく振ると、簡単に CPU 使用率は 100% になります。


Jittaさんと同じ条件で今試しましたが、XPでもVistaでも、そう簡単に100%にはなりません。
XPは50%台、Vistaは20%台です。


私も同じくらいの数字でした。


引用:

>.NET Framework アプリケーションが CPU を占有していることを、どの様に確認されたのでしょうか。
引用:

MFCアプリとの違いはあるという話ですよね。
じゃあ多少なりとも.Netアプリに問題があると。
そーゆー論理展開かと。




そーゆー論理でした。


Jittaさんからのコメントですが、
引用:

試験方法と計測方法を、私が同じ計測ができるように、説明してください。


試験方法は、お手数ですが最初に述べたアプリを作って頂けたらよいかと思いますが、
計測方法は難しいですね・・・それこそCPUやGPUの性能に依存してしまいますので。


解決には至らなかったですが、皆様から有益な情報を頂きまして、大変感謝致しております。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2007-07-24 21:58
ブログのネタにさせていただきます。
_________________
れい
ぬし
会議室デビュー日: 2005/11/01
投稿数: 346
投稿日時: 2007-07-24 23:44
引用:

Jittaさんの書き込み (2007-07-20 19:49) より:
↓投稿数増やすこともないので編集で失礼
仮想OSでやったので、簡単にCPU負荷が上がります当然、ゲストを観測していますよ。



投稿数増やすのがいやでないなら
投稿していただけると私には見やすいです。

返信しづらいし気づかないので。

引用:

フォーカスを持つアプリケーションは、優先順位がチョビット上がります。描画が必要なのは、非アクティブなアプリケーションではなく、アクティブなアプリケーションですから、ドラッグしているアプリケーションの負荷と、計測したいアプリケーションの負荷が明確に分けられる必要があると思います。
そこをどうやって分けたのかな?と見直してみましたが、書かれていないように思います。



Jittaさんの言うように、
この話は負荷の由来を調べるのがちょっと難しいですよね。
前面のアプリの再描画、
背面の件のアプリの再描画、
その後ろのデスクトップの再描画があり、

さらにWM_PAINTは優先順位が低くて、
描画すべきものがあってもIdleに入らないと送られて来ません。
窓の位置変化の測定頻度も負荷状況によって変わりますし。

(CPU Usageが100%でも実はまだ余裕があるという意味でもあるんですが。)

ですが、全てをきちんと理解していなくても、
差を測定すれば問題は分離できます。

今回はMFCと差をみてるという話です。
(ぜんぜん違う環境で試したりはしていませんよね?)
他の条件が全て同じなら、
.Netの描画が重いと言うことができます。

私の環境では
空フォーム・電卓・IE・以前作ったタブにラベルが60個ついたフォーム

.Netフォーム・MFCフォーム
の前で振ってあまり差が見られなかった(もちろん100%になったりしない)ので、
「udonさんの言っているような問題は起こらない」ということ以外、
確実なことは何もいえません。

udonさんはMFCとの差が明確にわかるというような話ですので、
udonさんの環境ではMFCとずいぶん差があるんでしょう。

>解決には至らなかったですが、皆様から有益な情報を頂きまして、大変感謝致しております。

ダブルバッファにしろBitBltにしろWM_PAINT間引きにしろ、
きちんと実装せずに、もしくは実装した結果を示さずに
「解決に至らなかった」としているのが残念ですが、
MFCで要求を満たすのであればそれを使うのがよいと思います。
udon
会議室デビュー日: 2007/07/15
投稿数: 13
投稿日時: 2007-07-25 12:58
れいさん、Jittaさん 4ページ目までお付き合い頂き感謝しております。
#恐らく最後の書き込みです

引用:

引用:

フォーカスを持つアプリケーションは、優先順位がチョビット上がります。描画が必要なのは、非アクティブなアプリケーションではなく、アクティブなアプリケーションですから、ドラッグしているアプリケーションの負荷と、計測したいアプリケーションの負荷が明確に分けられる必要があると思います。
そこをどうやって分けたのかな?と見直してみましたが、書かれていないように思います。


Jittaさんの言うように、この話は負荷の由来を調べるのがちょっと難しいですよね。
前面のアプリの再描画、背面の件のアプリの再描画、その後ろのデスクトップの再描画があり、


ご指摘の通り、CLRアプリの負荷なのか、移動しているアプリの負荷なのか
記載をしていませんでした。
厳密な確認ではありませんが、手前をグリグリ移動するウィンドウとして
メモ帳のウィンドウサイズをタイトルバーの文字が表示される程度に小さくし、
そのウィンドウを、問題のCLRアプリや、XPで画像を表示する標準ビューアーの
手前でグリグリ動かし、タスクマネージャーのプロセスタブにて、負荷率を確認しました。
結果としてはCLRアプリのCPU使用率が80〜100になっておりました。

引用:

私の環境では空フォーム・電卓・IE・以前作ったタブにラベルが60個ついたフォームを
.Netフォーム・MFCフォームの前で振ってあまり差が見られなかった
(もちろん100%になったりしない)ので、
「udonさんの言っているような問題は起こらない」ということ以外、確実なことは何もいえません。

udonさんはMFCとの差が明確にわかるというような話ですので、
udonさんの環境ではMFCとずいぶん差があるんでしょう。


む、れいさんの環境ではMFCとCLRの殆ど差が無かったのですか。
OSの設定の問題のようにも思えてきました。

引用:

引用:

>解決には至らなかったですが、皆様から有益な情報を頂きまして、大変感謝致しております。


ダブルバッファにしろBitBltにしろWM_PAINT間引きにしろ、きちんと実装せずに、もしくは実装した結果を示さずに
「解決に至らなかった」としているのが残念ですが、MFCで要求を満たすのであればそれを使うのがよいと思います。


そうですね。私のスタンスとしては「これから作り始める」というものでしたので、
半ば「諦め」的な結論の出し方をした事は否めません。
私の考えとして、「表示の最適化(CPU使用率を下げる意味で)」を検討しなければいけない時間、
言い換えれば、見積りとして提示する事が難しいと判断しました。
お客様から言わせれば「そんな事(CPU負荷率を下げる表示処理)をわざわざ調べたり作らないといけないの?」
という事になります。
開発環境としてお客様から「VC.Netを使え」、と言った以上、それを用いた結果、
「パフォーマンスで問題がありました。こちらは言われた通りのツールを使っただけですよ」
という流れになったらお客様も気の毒ですので、リスク回避の意味が強いです。

ダブルバッファについては、実装が簡単そうだったのでやってみましたが、結果はでませんでしたね。
WM_PAINTの間引きについてですが、これは絶対無いです(笑)
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2007-07-25 18:29
れいさん:
本題からずれるので、次の投稿で気づいてもらえたらいいか、と思ったのですが、ページが別れたのは想定外でした。申し訳ない。


udonさん:
どうして全体を見るんだろう?プロセス毎の報告を見て欲しいな。
と、おもいました。
未記入
会議室デビュー日: 2007/06/05
投稿数: 5
投稿日時: 2007-07-25 18:57
マルチポスト

http://dobon.net/cgi-bin/vbbbs/cbbs.cgi?mode=al2&namber=20077&rev=&no=0

スキルアップ/キャリアアップ(JOB@IT)