キャンバスとラベルの比較 - ページ 8 123456789101112131415...18 新しいコメント fxsaber 2021.03.13 19:52 #71 Nikolai Semko:ああ、内部チャートだとは思わなかったよ。 プロファイリングから判断すると、グラフをスクロールしたときのブレーキの原因は、このラインにありますね。アクティブスクロールによるプロファイリング。スクロールを行わず、マウスをアクティブに動かした状態でのプロファイリング(LKMを押さない状態)。ZS: ブレーキの源は、やはりカンヴァスではなく、オブジェなのですね。 残念ながら、このコードのプロファイリングは空白になりました。b2828. Nikolai Semko 2021.03.13 19:57 #72 fxsaber:残念ながら、このコードのプロファイリングは空白になりました。b2828. プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。でも、今はうまくいっています。 これでもかというほど効きます。 Mihail Matkovskij 2021.03.13 19:57 #73 Renat Fatkhullin:これは間違ったアプローチです。特にビジュアルテスターは遅延レンダリングモデルが異なるので、テストプロセスを完全に遅らせることができないように。 なるほど、テスターでの測定に 加え、チャートでの測定が必要になるわけですね。 Renat Fatkhullin: そんなこと言ってませんよ。明らかな誤りを指摘し、レンダリングシステムの仕組みを説明しました。 じゃあ、私は勘違いしていたんですね。すみません。 fxsaber 2021.03.13 20:53 #74 Nikolai Semko:プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。しかし、現在は動作しています。 こちらも有効です。 b2830でも何も出ませんでした。 Aleksey Mavrin 2021.03.13 21:03 #75 Igor Makanu:Windowsのイベントモデル で、マウスを素早く動かすと、どのアプリケーションにフォーカスがあっても、CPUの負荷が 増加し始める。SZY: Win10のタスクマネージャーで確認したところ...。Win7ではマウスを素早く動かすと全く同じ負荷がかかっていたのに、なぜかCPU負荷の上昇が見られない。Win10ではイベントモデルが大幅に変更されたとは思えないので、おそらくタスクマネージャの動作が異なるのだろう Vin10です。このテキストメッセージの入力ウィンドウで、LKMを押しながらマウスを動かすと、次のようなプロットが得られます。 LKMなしはこちら Igor Makanu 2021.03.13 21:22 #76 Aleksey Mavrin:Vin10です。このテキストメッセージの入力ウィンドウでLKMを押したままマウスを動かすと、次のようなプロットが得られます。こちらはLKMなし。 わかりにくい Win7での仮想デスクトップです。マウスを動かさないと、CPUに3~4%負荷がかかります。 マウスが速く動いている場合 - 11-14%の負荷 つまり、Winのメッセージキューは常に処理される必要がありますが、それは余分なCPUサイクルを必要とします。 Aleksey Mavrin 2021.03.13 21:26 #77 Igor Makanu:図解しないWin7で仮想マシンから、マウスを動かさない場合、CPUに3〜4%の負荷がかかるマウスの動きが速い場合 - CPU負荷11~14%。つまり、Winのメッセージキューは常に処理される必要があり、CPUサイクルを余分に消費するのです。もっとわかりやすく数字で言うと、何もしていないのに、10~15が変動し、動くと17~30になる。しかし、これでOnTimerの速度が2倍遅くなるかというと、もちろんそうではなく、95~99%の負荷のときを除けば、そうなります。 C++でWinAPIを使ってWindowsのウィンドウ・アプリケーションを書くためのマニュアルがあれば、メッセージ・ハンドラについて読んでみてください。 メッセージハンドラは、キューがないときには使われないだけで、そのままではCPUの何分の一かを消費します。MTプロセスでは、この負荷によるプロセッサ時間の短縮はないはずです。 Igor Makanu 2021.03.13 22:02 #78 Aleksey Mavrin:しかし、それによってOnTimerが2倍遅くなるかというと、もちろんそうではなく、95〜99%の負荷の場合を除けば、そうなります。 timerもWinAPIイベントですが、すべてのMQLプログラムがシステムタイマーをサブスクライブしているかどうかは疑問です - これはMQL環境(仮想マシン)をエミュレートしています Aleksey Mavrin: メッセージハンドラがCPUを占有するなど、キューがないときには使われないだけです。MTプロセスの場合、この負荷ではCPU時間のカットはないはずです。 アクティブなウィンドウには常にキューがあり、このキューがターミナルによってチャート間やMQLプログラム間でどのように分配されるかは、一般的なコーヒーリーフの推測に過ぎません。 まあ、最終的には - 独占モードを取得し、メッセージを処理しないように - 多くのオプションは、来る最初の - 排他的なフルスクリーンモードのアプリケーションが、それは別の話だ、"リソースのPCのための戦い "のように、その後、ちょうど交換に行くとあなたのアプリケーションを書くためにAPIを必要とし、そこにウィンドウかどうかを登録することです CPU負荷のピークを探すことには興味がない。Vinにいる限り、何が起こっても不思議ではない。 Andrei Trukhanovich 2021.03.13 22:04 #79 Igor Makanu:timerもWinAPIイベントですが、すべてのMQLプログラムがシステム・タイマーをサブスクライブしているかどうかは疑問です。 端末のタイマーとハンドラの数に関するバグがあったことを思い出すと、MTの各タイマーがシステムワンプレイである可能性を間接的に示唆しています。 fxsaber 2021.03.13 22:09 #80 MT4では、状況はより興味深いです(コードは クロスプラットフォームです) - OnTimerは、もはやマウスが移動したときに呼び出されることはありません。 123456789101112131415...18 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ああ、内部チャートだとは思わなかったよ。
プロファイリングから判断すると、グラフをスクロールしたときのブレーキの原因は、このラインにありますね。
アクティブスクロールによるプロファイリング。
スクロールを行わず、マウスをアクティブに動かした状態でのプロファイリング(LKMを押さない状態)。
ZS: ブレーキの源は、やはりカンヴァスではなく、オブジェなのですね。
残念ながら、このコードのプロファイリングは空白になりました。b2828.
残念ながら、このコードのプロファイリングは空白になりました。b2828.
プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。でも、今はうまくいっています。
これでもかというほど効きます。
これは間違ったアプローチです。特にビジュアルテスターは遅延レンダリングモデルが異なるので、テストプロセスを完全に遅らせることができないように。
なるほど、テスターでの測定に 加え、チャートでの測定が必要になるわけですね。
そんなこと言ってませんよ。
明らかな誤りを指摘し、レンダリングシステムの仕組みを説明しました。
じゃあ、私は勘違いしていたんですね。すみません。
プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。しかし、現在は動作しています。
こちらも有効です。
b2830でも何も出ませんでした。
Windowsのイベントモデル で、マウスを素早く動かすと、どのアプリケーションにフォーカスがあっても、CPUの負荷が 増加し始める。
SZY: Win10のタスクマネージャーで確認したところ...。Win7ではマウスを素早く動かすと全く同じ負荷がかかっていたのに、なぜかCPU負荷の上昇が見られない。Win10ではイベントモデルが大幅に変更されたとは思えないので、おそらくタスクマネージャの動作が異なるのだろう
Vin10です。このテキストメッセージの入力ウィンドウで、LKMを押しながらマウスを動かすと、次のようなプロットが得られます。
LKMなしはこちら
Vin10です。このテキストメッセージの入力ウィンドウでLKMを押したままマウスを動かすと、次のようなプロットが得られます。
こちらはLKMなし。
わかりにくい
Win7での仮想デスクトップです。マウスを動かさないと、CPUに3~4%負荷がかかります。
マウスが速く動いている場合 - 11-14%の負荷
つまり、Winのメッセージキューは常に処理される必要がありますが、それは余分なCPUサイクルを必要とします。
図解しない
Win7で仮想マシンから、マウスを動かさない場合、CPUに3〜4%の負荷がかかる
マウスの動きが速い場合 - CPU負荷11~14%。
つまり、Winのメッセージキューは常に処理される必要があり、CPUサイクルを余分に消費するのです。
もっとわかりやすく数字で言うと、何もしていないのに、10~15が変動し、動くと17~30になる。
しかし、これでOnTimerの速度が2倍遅くなるかというと、もちろんそうではなく、95~99%の負荷のときを除けば、そうなります。
C++でWinAPIを使ってWindowsのウィンドウ・アプリケーションを書くためのマニュアルがあれば、メッセージ・ハンドラについて読んでみてください。
しかし、それによってOnTimerが2倍遅くなるかというと、もちろんそうではなく、95〜99%の負荷の場合を除けば、そうなります。
timerもWinAPIイベントですが、すべてのMQLプログラムがシステムタイマーをサブスクライブしているかどうかは疑問です - これはMQL環境(仮想マシン)をエミュレートしています
メッセージハンドラがCPUを占有するなど、キューがないときには使われないだけです。MTプロセスの場合、この負荷ではCPU時間のカットはないはずです。
アクティブなウィンドウには常にキューがあり、このキューがターミナルによってチャート間やMQLプログラム間でどのように分配されるかは、一般的なコーヒーリーフの推測に過ぎません。
まあ、最終的には - 独占モードを取得し、メッセージを処理しないように - 多くのオプションは、来る最初の - 排他的なフルスクリーンモードのアプリケーションが、それは別の話だ、"リソースのPCのための戦い "のように、その後、ちょうど交換に行くとあなたのアプリケーションを書くためにAPIを必要とし、そこにウィンドウかどうかを登録することです
CPU負荷のピークを探すことには興味がない。Vinにいる限り、何が起こっても不思議ではない。
timerもWinAPIイベントですが、すべてのMQLプログラムがシステム・タイマーをサブスクライブしているかどうかは疑問です。
端末のタイマーとハンドラの数に関するバグがあったことを思い出すと、MTの各タイマーがシステムワンプレイである可能性を間接的に示唆しています。