記事"グラフィカルインタフェースX: 標準チャートコントロール(ビルド4)"についてのディスカッション - ページ 3 123456 新しいコメント Реter Konow 2016.10.27 10:49 #21 Anatoli Kazharski:あなたは間違っている。なぜこのようにしたのかは、上のコメントですでに十分詳しく答えている。現在では、多くのリソースを消費することはありません（Windows 10でも 同様です）。記事（とコメントも）を読みましたか？//---P.S. ところで、異なるターミナル（MT4/MT5）とOSバージョン（Windows）でのCPUリソース消費は、同じ条件下でも大きく異なります。Windows 7では、MetaTrader 4 ターミナルはMetaTrader 5よりも かなり優れていました。残念ながら、私はすでにWindows 10に 完全に切り替えたので、今はその数字をお伝えすることはできません。最適化に関しては、私はまだすべてのオプションを使い果たしていません。まだ最適化すべきものがあり、その方法も理解しています。何かを加速スクロールさせたり、カーソル下のオブジェクトの色を スムーズに変えたりするには、タイマーが必要 だ。ここはすべて正しい。しかし、アイドル状態で最大10パーセントのリソース消費を引き起こすことはできない。問題は別のところにある。それは何か？Возможно проблема в вызове функции CheckElementsEventsTimer(), каждые 16 мс?つまり、タイマーのイベントごとに、すべてのインターフェイス要素のイベントをチェックするのか？なぜですか？このチェックの中に、プロセッサに負荷をかけるようなものがあるのでしょうか？ Anatoli Kazharski 2016.10.27 10:52 #22 例えば、何もないチャートの領域（グラフィカル・オブジェクトやMQLアプリケーション）でマウス・カーソルを動かすと、CPU消費量はすでに6～7%まで 上昇している：テスト前テスト中： Anatoli Kazharski 2016.10.27 10:59 #23 Реter Konow:何かを加速スクロールさせたり、カーソル下のオブジェクトの色を スムーズに変えたりするには、タイマーが必要だ。ここではすべてが正しい。しかし、アイドル状態で最大10パーセントのリソース消費を引き起こすことはできない。問題は別のところにある。それは何か？つまり、タイマーのイベントごとに、すべてのインターフェイス要素のイベントをチェックするのか？なぜですか？今は、カーソルを動かした瞬間だけチェックするように実装されている。しかも、これはWindows 10だけ である。Windows 7では そうではなかった。 そして、もしあなたが提案した方法を使うのであれば、カーソルが今置かれている要素の配列を準備するのに同じコストがかかることになり、さらに他の問題も出てきます。この方法はすでにテストしましたが、実際に得るものがないのであきらめました。他にもいくつか選択肢はあるが、まだテストが必要だ。もし得るものがあれば、次の記事で紹介する予定である。 Реter Konow 2016.10.27 11:01 #24 Anatoli Kazharski:例えば、何もないチャートの領域（グラフィカル・オブジェクトやMQLアプリケーション）でマウス・カーソルを動かすと、CPU消費量はすでに6～7%まで 上昇している：テスト前：テスト中：残念ながら、この事実を最適化することはできない。しかし、タイマーイベント（私の意見では、頻度が高すぎる。 16ミリ秒の代わりに25ミリ秒にすることもできる）で制御エレメントの 状態をチェックしても、このチェック中にリソースを消費するアクションが実行されなければ、リソースの消費は増加しないはずである。 Anatoli Kazharski 2016.10.27 11:01 #25 Реter Konow:...プロセッサーに負担をかけるようなテストとは？...しかし、タイマー・イベント（頻度が高すぎると思います。 16ミリ秒の代わりに25ミリ秒に設定することもできます）でコントロール・エレメントの状態をチェックすることは、リソースの消費を増加させるものではありません、 もし、このチェック中にリソースを消費するアクションが実行されなければ。 変化を表示するためのチャートの再描画。 Реter Konow 2016.10.27 11:10 #26 Anatoli Kazharski:現在はカーソルを動かした瞬間だけ表示されるように実装されている。これはウィンドウズ10だけ である。Windows 7では このようなことはなかった。 そして、もしあなたが提案した方法を使うなら、カーソルが今置かれている要素の配列を準備するのに同じコストがかかることになり、さらに他の問題も出てくる。 この方法はすでにテストしましたが、実際に得るものがないのであきらめました。他にもいくつか選択肢はあるが、まだテストが必要だ。もしゲインがあれば、次の記事で紹介する予定だ。1.そしてここで、あなたはすでに間違っている。要素の座標とサイズを持つマップ配列を準備し、ウィンドウを移動するイベントでそれらの値を調整しても、プロセッサの負荷は大きく増加しない。それ以外のカーソル移動の場合、座標再計算機能は呼び出されません。2.2.カーソルを動かしただけでは、ローカライザー関数が呼び出さ れ、要素のマップをループし、カーソルの下にあるオブジェクトを見つけます。この処理は純粋に計算であり、プロセッサに負荷をかけることはありません。 Anatoli Kazharski 2016.10.27 11:16 #27 Реter Konow: 要素の座標とサイズを持つマップ配列を用意し、ウィンドウの移動イベントでその値を修正することは、カーソルの移動イベントとウィンドウのハンドルをつかむときだけの作業なので、プロセッサの負荷を大きくすることはない。だから意味がない のだ。目的は、プロセッサの負荷を増やすことではなく、たとえそれが取るに足らないものであっても、逆に減らすことなのだ。私が間違っていないことがわかった。) Реter Konow 2016.10.27 11:18 #28 Anatoli Kazharski: 変化を示すためにチャートを描き直す特定の要素に対してポイント・バイ・ポイントで変更を加えることができるのに、なぜチャート全体を再描画するのでしょうか？16ミリ秒ごとに変更の必要性をチェックし（チェックはロードしない）、必要なときだけ特定のオブジェクトに変更を適用し、チャート全体を再描画しないようにすることができます。 Anatoli Kazharski 2016.10.27 11:31 #29 Реter Konow:特定の要素に関連して、ポイントごとに変更を加えることができるのに、なぜチャート全体を再描画するのでしょうか？チャートに変更を加えるたびに、ChartRedraw() 関数を呼び出して即座に表示する必要があります。キャンバスへの描画も同様です。したがって、最初にすべての要素に変更を加え、その後で初めてチャートが再描画されます。Konowタグ：16msごとに変更の要否をチェックし（チェックはロードしない）、必要なときだけ特定のオブジェクトに変更を適用し、チャート全体を再描画しない。今は16msごとに何も再描画されません。ユーザーが止まることなくグラフ上でマウスカーソルで円を切るようなことはない。現在の実装では、CPUリソースの消費は6～7％を超えることはありません。 Реter Konow 2016.10.27 11:40 #30 Anatoli Kazharski:チャートを変更するたびに、ChartRedraw() 関数を呼び出して即座に表示する必要があります。キャンバスへの描画も同様です。そのため、まずすべての要素に変更が加えられ、その後で初めてチャートが再描画される。これはとてもとても奇妙なことです。私のインターフェースの実装には、ChartRedraw() 関数の呼び出しは一度もない。なぜそれが必要なのか、今までよくわからなかったのですが......。私はそれなしでキャンバス（ビットマップオブジェクト）を使っている。仮にChartRedraw() 関数が必要だとすると、各オブジェクトを変更するたびに、すべてのオブジェクトの完全な再描画が必要になるということですか？ 123456 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
あなたは間違っている。なぜこのようにしたのかは、上のコメントですでに十分詳しく答えている。
現在では、多くのリソースを消費することはありません（Windows 10でも 同様です）。記事（とコメントも）を読みましたか？
//---
P.S. ところで、異なるターミナル（MT4/MT5）とOSバージョン（Windows）でのCPUリソース消費は、同じ条件下でも大きく異なります。Windows 7では、MetaTrader 4 ターミナルはMetaTrader 5よりも かなり優れていました。残念ながら、私はすでにWindows 10に 完全に切り替えたので、今はその数字をお伝えすることはできません。
最適化に関しては、私はまだすべてのオプションを使い果たしていません。まだ最適化すべきものがあり、その方法も理解しています。
何かを加速スクロールさせたり、カーソル下のオブジェクトの色を スムーズに変えたりするには、タイマーが必要 だ。ここはすべて正しい。
しかし、アイドル状態で最大10パーセントのリソース消費を引き起こすことはできない。問題は別のところにある。それは何か？
つまり、タイマーのイベントごとに、すべてのインターフェイス要素のイベントをチェックするのか？なぜですか？
このチェックの中に、プロセッサに負荷をかけるようなものがあるのでしょうか？
例えば、何もないチャートの領域（グラフィカル・オブジェクトやMQLアプリケーション）でマウス・カーソルを動かすと、CPU消費量はすでに6～7%まで 上昇している：
テスト前
テスト中：
何かを加速スクロールさせたり、カーソル下のオブジェクトの色を スムーズに変えたりするには、タイマーが必要だ。ここではすべてが正しい。
しかし、アイドル状態で最大10パーセントのリソース消費を引き起こすことはできない。問題は別のところにある。それは何か？
つまり、タイマーのイベントごとに、すべてのインターフェイス要素のイベントをチェックするのか？なぜですか？
今は、カーソルを動かした瞬間だけチェックするように実装されている。しかも、これはWindows 10だけ である。Windows 7では そうではなかった。
そして、もしあなたが提案した方法を使うのであれば、カーソルが今置かれている要素の配列を準備するのに同じコストがかかることになり、さらに他の問題も出てきます。この方法はすでにテストしましたが、実際に得るものがないのであきらめました。
他にもいくつか選択肢はあるが、まだテストが必要だ。もし得るものがあれば、次の記事で紹介する予定である。
例えば、何もないチャートの領域（グラフィカル・オブジェクトやMQLアプリケーション）でマウス・カーソルを動かすと、CPU消費量はすでに6～7%まで 上昇している：
テスト前：
テスト中：
残念ながら、この事実を最適化することはできない。
しかし、タイマーイベント（私の意見では、頻度が高すぎる。 16ミリ秒の代わりに25ミリ秒にすることもできる）で制御エレメントの 状態をチェックしても、このチェック中にリソースを消費するアクションが実行されなければ、リソースの消費は増加しないはずである。
...
プロセッサーに負担をかけるようなテストとは？
...
しかし、タイマー・イベント（頻度が高すぎると思います。 16ミリ秒の代わりに25ミリ秒に設定することもできます）でコントロール・エレメントの状態をチェックすることは、リソースの消費を増加させるものではありません、
もし、このチェック中にリソースを消費するアクションが実行されなければ。
現在はカーソルを動かした瞬間だけ表示されるように実装されている。これはウィンドウズ10だけ である。Windows 7では このようなことはなかった。
そして、もしあなたが提案した方法を使うなら、カーソルが今置かれている要素の配列を準備するのに同じコストがかかることになり、さらに他の問題も出てくる。 この方法はすでにテストしましたが、実際に得るものがないのであきらめました。
他にもいくつか選択肢はあるが、まだテストが必要だ。もしゲインがあれば、次の記事で紹介する予定だ。
1.そしてここで、あなたはすでに間違っている。要素の座標とサイズを持つマップ配列を準備し、ウィンドウを移動するイベントでそれらの値を調整しても、プロセッサの負荷は大きく増加しない。それ以外のカーソル移動の場合、座標再計算機能は呼び出されません。
2.2.カーソルを動かしただけでは、ローカライザー関数が呼び出さ れ、要素のマップをループし、カーソルの下にあるオブジェクトを見つけます。この処理は純粋に計算であり、プロセッサに負荷をかけることはありません。
Реter Konow:
要素の座標とサイズを持つマップ配列を用意し、ウィンドウの移動イベントでその値を修正することは、カーソルの移動イベントとウィンドウのハンドルをつかむときだけの作業なので、プロセッサの負荷を大きくすることはない。
だから意味がない のだ。目的は、プロセッサの負荷を増やすことではなく、たとえそれが取るに足らないものであっても、逆に減らすことなのだ。私が間違っていないことがわかった。)
変化を示すためにチャートを描き直す
特定の要素に対してポイント・バイ・ポイントで変更を加えることができるのに、なぜチャート全体を再描画するのでしょうか？
16ミリ秒ごとに変更の必要性をチェックし（チェックはロードしない）、必要なときだけ特定のオブジェクトに変更を適用し、チャート全体を再描画しないようにすることができます。
特定の要素に関連して、ポイントごとに変更を加えることができるのに、なぜチャート全体を再描画するのでしょうか？
チャートに変更を加えるたびに、ChartRedraw() 関数を呼び出して即座に表示する必要があります。キャンバスへの描画も同様です。したがって、最初にすべての要素に変更を加え、その後で初めてチャートが再描画されます。
Konowタグ：
16msごとに変更の要否をチェックし（チェックはロードしない）、必要なときだけ特定のオブジェクトに変更を適用し、チャート全体を再描画しない。
今は16msごとに何も再描画されません。ユーザーが止まることなくグラフ上でマウスカーソルで円を切るようなことはない。現在の実装では、CPUリソースの消費は6～7％を超えることはありません。
チャートを変更するたびに、ChartRedraw() 関数を呼び出して即座に表示する必要があります。キャンバスへの描画も同様です。そのため、まずすべての要素に変更が加えられ、その後で初めてチャートが再描画される。
これはとてもとても奇妙なことです。私のインターフェースの実装には、ChartRedraw() 関数の呼び出しは一度もない。
なぜそれが必要なのか、今までよくわからなかったのですが......。私はそれなしでキャンバス（ビットマップオブジェクト）を使っている。
仮にChartRedraw() 関数が必要だとすると、各オブジェクトを変更するたびに、すべてのオブジェクトの完全な再描画が必要になるということですか？