プログラミングボード
プログラミングボード

HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 検索 過去ログ

■ 新規投稿からどんどん投稿してください!

[全スレッド3件(1-3 表示)] 全ページ数 / [0]
親記事の順番 [レス最新順/投稿順/記事数順]

記事リスト ( )内の数字はレス数
タスクマネージャーの暴走(1) | 独り言(0) | VC++ MFC Tips(2) |


■48 / 親記事)  タスクマネージャーの暴走
□投稿者/ Toshi -(2016/02/26(Fri) 17:03:29)

    プログラミングの話では有りませんが、32bit版Windowsを使ってて、OS自体が滅茶苦茶重くなる事が有ります。
    私は常にタスクマネージャーを起動しっぱなしにしてる人間なのですが、タスクマネージャーでCPU使用率を確認すると、タスクマネージャー自身、つまり「taskmgr.exe」のCPU使用率が40〜50%と、デュアルコアなので、つまりCPU一つを丸々占有してる状態でOS全体の処理が重くなります。

    以前からこの現象はちょくちょく有ったのですが、知らない間に現象が収まる事が多かったので、今まで「ま、いっか」と気にしてませんでした。

    しかし、最近、またこの現象が頻繁に起きて私を困らせます。
    そこで今回は色々調べてみました。

    結論から言うと、詳しい事は分からなかった・・・です。

    しかし、有る程度、原因が推測出来るだけの材料は揃ったと思います。

    原因は、グラフィック性能のしょぼさ、です。

    まず、この現象が起きる前提として、処理の重たいデコードによる再生の途中からこの現象が出始め、動画がスムーズに再生されなくなり、動画をポーズしてタスクマネージャで確認すると、この時点で既にタスクマネージャのCPU使用率が高くなってます。
    また、ePSXeなど、高いグラフィック処理を要求するアプリケーションを使ってても、10分もしない内に同様の現象が発生します。

    ノートPCでチップ内臓のグラフィックコントローラーを使用しているのですが、その様なPCは大抵の場合、メインメモリをグラフィックメモリとして利用しています。
    メインメモリは本格的なグラフィックボードと違って非常に処理の遅いメモリです。
    しかも、割り当てられるメモリは少ないです。
    昨今のグラフィックボードでは、ギガレベルのメモリを搭載してますが、メインメモリを利用する内蔵チップ型の場合、精々128〜256Mバイト程度しか利用してないと思います。(下手すれば64Mバイト程度って事も有り得ます。)

    最近の動画のデコードは高いグラフィック性能と有る程度のメモリを要求します。
    ePSXeなども同じです。

    これらのアプリは、画面に表示する動画アニメーションをスムーズに再生しようとして、沢山の情報を先読みし、バッファリングします。
    しかし、メモリが小さいので、すぐにバッファリングが詰まってしまいます。
    しかも処理が遅いので、バッファの中から再生済みのいらないメモリを破棄し、新たな情報を読み込む、と言うキャッシュ制御が詰まります。
    つまり、内蔵チップによるメモリ制御の処理待ちでメディアプレイヤーやePSXeなどは「まだですか?」と繰り返し確認する為だけにCPU負荷を取られる訳です。
    それは、リアルタイムで画面を更新するタスクマネージャーも例外では有りません。
    タスクマネージャーもGDIと言うグラフィックコアに「画面を更新してくれ」とリクエストをしますが、GDIは「まだグラフィックのキャッシュ処理が終ってないから、待っててよ」と返します。タスクマネージャはしばらく待てば良いのに、プログラミングされた通りの高速リトライで再確認に行ってしまうので、ビジー率が跳ね上がってしまう、と言う訳です。

    その様な事情なので、仮にタスクマネージャを終了させても、内臓チップによるメモリ掃除処理に掛かる時間自体は大して変わらないので、メディアプレイヤーやePSXe自体がスムーズに動く様にはなりません。

    つまり、内臓チップのキャッシュ掃除が終われば、自然とタスクマネージャの負荷は通常値(10%前後)に落ちます。
    しかし、この後引き続き動画やゲームを再開すると、同じく重いままです。
    それは、詳細なグラフィックデータがキャッシュに一杯溜まったままだからです。
    つまり、掃除は完璧に行われていない、と言う事になります。
    このゴミとなった「詳細なグラフィックデータ」を掃除するには、「簡易なグラフィックデータで一杯にしてやれば良い」と言う事になります。
    つまり、処理の軽いアプリケーションのウィンドウを最大化したり最小化したり、テキストベースのインターネットページを閲覧するなどです。
    そうすると、内臓チップはメモリに残ったゴミ掃除を簡単に出来る様になりますから、動画やゲームを再開した際にしばらくはスムーズに動く様になります。

    つまり、根本的解決方法は今の所「無い」と言う事になります。
    グラフィック性能の良いノートPCに買い換えるか、若しくは重くなったらしばらく休んで、またちょっと動かし、また休んで、を繰り返し使うかしか選択肢は無い状況かなと思います。

    呪わしくは、ハード性能に頼ったソフトウェア文化の台等ですね。

    尚、姑息な手段では有りますが、動画だけなら回避方法が無い事も有りません。
    それは、デコード処理が比較的軽い、MPEG2若しくはMPEG1にコンバートしてから再生する、と言う方法です。
    デュアルコア世代のノートPCなら、MPEG2なら問題なく再生出来ると思います。

→ 親記事 / 引用返信
▽[全レス1件(ResNo.1-1 表示)]
■49 / ResNo.1)  タスクマネージャーの暴走:結論
□投稿者/ Toshi -(2016/06/26(Sun) 12:20:02)

    その後色々と試行錯誤して原因が明確に分かりました。
    蓋を開けてみれば「そんな事か」と言う単純な話だったのですが、熱暴走でした。
    まさか、近年のPCで熱暴走が起きるとは考えておらず、全くの盲点でした。

    グラフィックはノートPCの為オンチップなので、結局グラフィック処理が一番CPU負荷が高くなって熱暴走しやすくなる、と言う話です。

    私はノートPCを寝床で使ってる都合上、ノートPC付属のキーボードは使い勝手が悪く、USB外付けでキーボードを繋げて使ってます。
    そしてノートPCのキーボードは、なんか調子が悪くてキータップと入力キーを認識する為の敷かれているタッチセンサー付き基盤シートを取っ払って、キーボード部分は丸裸になってます。(基盤シートを敷く為の鉄板がむき出しになってる)
    この状態なので、熱暴走と言う原因にたどり着けました。

    つまり、タスクマネージャーが暴走してる時の鉄板が滅茶苦茶熱い!

    と言う事で、ビニール袋に水を入れ、それをフリーザーで凍らせた氷を用意し、熱暴走した時には氷を鉄板に乗せてやる事で、すぐに収まる様になりました(笑)

    夏なんか熱暴走しやすくなるので、氷を二つ用意して二交代制で絶えず冷やしてる状態です。
    その作業が少し面倒ですけど、でも熱暴走しなくなったので快適に作業が出来る様になりました。

引用返信


レス記事表示 → [親記事-1]


■44 / 親記事)  独り言
□投稿者/ Toshi -(2009/03/27(Fri) 01:44:40)

     今更なグチなんですが、MFCを使っていてムカ付いてしょうがない点として、ウィザードのお粗末さが有ります。

     WP6PKエディタの様なコテコテギチギチなGUIを作っていると、無性に腹が立ってきます。

     一つは、各コンポーネントのテーブル化が出来ない点。
     似たようなエディトフィールドの羅列になるので、配列にしてループで処理しようとしても、配列に手作業で直してしまうとウィザードが動かなくなってしまうと言うどーしようも無いダサさにまずはムカッ!

     もう一つは、基底ダイアログクラスを作って、そこから派生ダイアログを構築する時に、基底クラスではダイアログID無指定でのウィザードが出来ない事と、仮に基本項目だけのダイアログを登録して、更に派生側でコンポーネントを追加する様な使い方も出来ないので、結局ウィザードを使おうとしたら「派生」と言う概念を捨てるか、またはウィザードを捨てるかの2択になってしまう点にムカッ!

     あと、実は今回初めてMFCでスピンコントロールを使って見たんですが、スピンコントロールってWin上での実装そのものがなんかダサくないですか?
     タブオーダ任せでアタッチ? 
     ありえね〜。

    (注:自宅では未だに VC6.0なので、最新のVCなら改善されてたかも・・・
      でも、.Net や 2005も職場で使った経験が有りますが、ウィザードは相変わらず
      ダサかった様な気が・・・)

→ 親記事 / 引用返信


■4 / 親記事)  VC++ MFC Tips
□投稿者/ Toshi -(2005/12/10(Sat) 14:08:59)

    このスレには、最近自分が VC++ + MFC でハマった事項やちょっとしたテクに対する Tips をメモ的に書いていきます。

→ 親記事 / 引用返信
▽[全レス2件(ResNo.1-2 表示)]
■5 / ResNo.1)  コンボボックス+イメージリスト
□投稿者/ Toshi -(2005/12/10(Sat) 14:22:55)

    イメージリストの扱いに関するWEBページは結構有りますが、どれもbmpファイルを読み込んで使用するパターンばかりです。
    今回、自分で描画したイメージをイメージリストに登録してコンボボックスに使用したかったのですが、ちょっとハマりました。
    そこで、ハマった点をまとめます。

    ・memDCに自分で描画して、GetCurrentBitmap()でビットマップイメージを取得し、イメージリストに登録する訳ですが、何も考えずにこれをやってもイメージリストに登録されるイメージは黒い豆腐になります。
    ポイントは、「.DeleteDC()」です。

    CBitmap *bitmap = memDC.GetCurrentBitmap();
    memDC.DeleteDC();
    imageList.Add(bitmap, (COLORREF)0);

    の手順で行えば正常に登録されます。

    ・またついつい忘れがちになってやってしまうのが、CComboBox を使ったり、DLGエディタでも普通のコンボボックスを貼り付けてしまう事です。
    CComboBoxEx と、Expanded ComboBox を使う必要が有ります。

引用返信

■6 / ResNo.2)  CStaticのカラー化
□投稿者/ Toshi -(2005/12/10(Sat) 14:58:10)

    (前提として、私はカプセル化出来るオーナードローを好んで使います。
     試した事は有りませんし、詳しく突っ込んで調べた事も無いのですが、
     コントロールカラーもリフレクターを使えばカプセル化出来るかも
     知れません。)

    CStatic を派生させて CColorStatic を作りました。
    しかし、どうも上手く動いてくれず、ハマりました。
    DLGエディッタで指定した各種プロパティがどうも無効になってしまうのです。
    調べた結果、オーナードローの値が 0x0d なのに、Allign周りのスタイル値が 0,1,2 だったり、とーもスタイル値の組み合わせが破綻してる様です。
    対策として、通常オナードローが指定されていないコントロールでも強引にオーナードローにする為に、PreSubclassWindow()で ModifyStyle()すると思いますが、
    その PreSubclassWindow() 内で ModifyStyle() する直前に、メンバー変数を用意し、
    m_dwOrgStyle = GetStyle();
    で、オーナードロースタイルを設定する前の値を保存しておき、DrawItem() では
    m_dwOrgStyle を使って色々描画制御してやる必要が有ります。

    また、オーナードロー時に GetWindowText() を行っても「\t」が取れず、また、CDC::DrawText() もタブを展開してくれないと言う問題も有りました。
    よってタブを使う際は、DLGエディッタで入力したデフォルトストリングを使う事は諦め、CColorStatic::SetText() を用意して別途メンバー変数 CString m_strText にテキストを保持させ、( PreSubclassWindow() 内で m_strText = GetWindowText() を行っておけばタブを使わない場合は DLGエディッタの文字が使える)DrawItem() では m_strTextを元に自前でタブ展開を行う必要が有ります。
    もちろん、ワードラップもしてくれないので、こいつも自前で処理する必要が有ります。
    この辺の処理は一度悩めばカラーボタンなどにも応用が効くので面倒でも関数を作る価値は有ります。
    (私が作ったワードラップメソッドは「えいや」なので、今回は提示を控えます)
    (私が作ったタブ展開メソッドはイメージリスト対応でちょっと複雑で分かり辛いので、今回は提示を控えます)
    ちなみに、カラーボタンは性能を考えなければ デフォルトで用意されているActiveX 使った方が早いですね。
    今の職場は 「ActiveX使われると誰もメンテできなくなるからやめて」って言う所だし、いずれにせよ ActiveX のカラーボタンは重いしで、自分で CColorButton 作りましたが・・・


引用返信


レス記事表示 → [親記事-2]



全ページ数 / [0]
全記事数/6 (親/3 レス/3)
キーワード/

削除/編集フォーム
記事No
(半角数字)
/
削除キー/
Pass/

HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 検索 過去ログ

-
Child Tree -