キャンバスとラベルの比較 - ページ 7

新しいコメント
 
Mihail Matkovskij:

どこかで詳しく読める情報はないでしょうか？かなり明確になったとはいえ、やはり面白いテーマですねー。あとは、ビットマップ更新制御の変形を行い、テストするのみです。ラベルよりビットマップの方が速いなんてことになったら、驚きです。

BitMap は MQL5 ではなく C++ で埋められるので、ラベルが少ない場合は、kanvas よりも速度的に有利であることは認めます。しかし、BitMapのテキスト形成は両者ともwin関数で行われているため、canvasでも同じように形成されるとは考えにくい。Labelの場合、これらのオブジェクトはイベントプロパティ（マウスでドラッグ＆ドロップできる）が充実しているので、結局は構築が重くなるのだと思います。

 

Canvasのスピードについて、疑問があります。


ビデオカードはCPUに内蔵されています。


このようなコードを実行する。

#include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit()
{  
  USAGE::MinInterval = 100 * 1000; // 100 ms.
  
  EventSetMillisecondTimer((int)USAGE::MinInterval / 1000);  
}

void OnTimer()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate(1200, 900, 200); // Вывели график нагрузки.
}

void OnDeinit( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

簡単に説明すると、100msごとにOnTimerがどれだけ実行されたかを測定します。また、OnTimerの内部で測定値のグラフを描画します。これが、その成果です。

15〜20％食ってしまう。どうやら、グラフィックカードが遅いようです。しかし、問題は別です。マウスで価格チャートをジャラジャラ動かし始めると（マウスの左ボタンを押しながら左右に動かすと）、負荷が2倍くらいになるんです。上のアニメーションでもはっきりと確認できます。この特殊性の理由は何でしょうか？


もう一度言います。マウスで価格チャートを動かすと、OnTimerは2倍の時間がかかります。

 
fxsaber:

Canvasのスピードについて、疑問があります。


ビデオカードはCPUに内蔵されています。


このようなコードを実行する。

簡単に説明すると、100msごとにOnTimerがどれだけ実行されたかを計測します。また、OnTimerの内部で測定値のグラフを描画します。これが、その成果です。

15〜20％食ってしまう。どうやら、グラフィックカードが遅いようです。しかし、問題は別です。マウスで価格チャートをジャラジャラ動かし始めると（マウスの左ボタンを押しながら左右に動かすと）、負荷が2倍くらいになるんです。上のアニメーションでもはっきりと確認できます。この特殊性の理由は何でしょうか？


もう一度言います。マウスで価格チャートを動かすと、OnTimerは2倍の時間を要します。

多くの場合、ライブラリには CHARTEVENT_CHART_CHANGE コントロールがあり、必要な場合（チャートサイズが変更された場合）にキャンバスサイズを変更しますが、それを見つけるには、恐ろしく遅い（今のところ）非同期関数 ChartGet...
これを実行すると遅くなることが分かっています。
MQ では、CHARTEVENT_CHART_CHANGE イベントを分離し、たとえば、CHARTEVENT_CHART_SIZE_CHANGE を別に作成する方が理にかなっています。CHARTEVENT_CHART_CHANGE イベントには、新しいバーの出現、バーのスクロール、垂直方向の価格スケールの変更、ウィンドウのサイズ変更など、多くの要素があります。

 
Nikolai Semko:
BitMap は MQL5 ではなく C++ で記入されているため、少数の Labels を使用する場合、Kanvas よりも速度的に有利である可能性は十分にあります。しかし、BitMapのテキスト形成は両者ともwin関数で行われているため、canvasでも同じように形成されるとは考えにくい。Labelの場合、これらのオブジェクトもイベントドリブンな性質（マウスでドラッグ＆ドロップできる）をまとっているので、結局は構造が重くなるのだと思います。

確かに、ラベルは高速化できる。チャートにいくつ入っているかにもよるが...。アップデートチェックを行い、その結果には確かに驚きました。目に優しい最小限のフレームレート、24fpsから取ったリミット。約41ミリ秒。カンヴァスに制限をかけて、あら不思議、驚きました。容赦ないラベルの更新に比べれば、まさに飛ぶ鳥を落とす勢いですしかし、Labelsの表示に同じ制限をかけると、Kanvasベースの表示よりもさらに高速になりました。しかし、先走ることなく、すべてのテスト 結果を後日紹介することにします。

 
fxsaber:

マウスで価格チャートをジャラジャラ動かし始めると（マウスの左ボタンを押したまま左右に移動）、負荷が2倍になります。上のアニメーションでは、それが完全に見えています。この特殊性の理由は何でしょうか？

Windowsのイベントモデル で、マウスを素早く動かしても、どのアプリケーションにフォーカスがあっても、CPUの負荷が増加し始めること

SZY：Win10のタスクマネージャーで確認したところ...。Win10でイベントモデルが劇的に変化したとは思えません。むしろタスクマネージャの動作が変わっている可能性が高いです

 
Nikolai Semko:

多くの場合、ライブラリには CHARTEVENT_CHART_CHANGE コントロールがあり、必要な場合（チャートサイズが変更された場合）にキャンバスサイズを変更することができますが、それを見つけるには、ひどく遅い（今のところ）非同期の ChartGet 関数を実行する必要があります...
このため、ブレーキがかかってしまいます。
MQ では、CHARTEVENT_CHART_CHANGE イベントを分離し、たとえば、CHARTEVENT_CHART_SIZE_CHANGE を別に作成する方が理にかなっています。CHARTEVENT_CHART_CHANGE イベントには、新しいバーが来る、バーがスクロールする、垂直方向の価格スケールが変わる、ウィンドウのサイズが変わるなど、様々なものがあります。

上記のコードには一切ありません。

 
Igor Makanu:

Windowsのイベントモデル で、マウスを素早く動かすと、どのアプリケーションにフォーカスがあっても、CPUの負荷が増加し始める。

SZY: Win10のタスクマネージャーで確認したところ...。Win7では、同じPCでマウスを素早く動かすと負荷が上がっていたのに、なぜかCPU負荷が上がっていない。Win10ではイベントモデルが根本的に変わっていないのだろうが、おそらくタスクマネージャーの動作が変わっているのだろう。

ありがとうございます、知りませんでした。マウスでMQLのプログラムが半分くらい遅くなることに驚き。

ZS この結果になったのは私だけでしょうか？
fxsaber:

15〜20％食ってしまう。どうやらビデオカードが遅いようです。

 
fxsaber:

ありがとうございます、知りませんでした。マウスを使うと、MQLのプログラムが半分くらい遅くなることに驚きました。

それなら、ティックなどでラグがあるのは正当なことです。このようなイベントモデルによる HFTは、まるで地雷原のようです。

 
fxsaber:

上記のコードには一切ありません。

ああ、内部チャートだとは思わなかったよ。
プロファイリングから判断すると、チャートをスクロールするときのブレーキの原因は、このライン上にありますね。

アクティブスクロールを用いたプロファイリング。

スクロールを行わず（LKMを押さずに）マウスをアクティブに動かした場合のプロファイリング。

ZS: つまり、ブレーキの元はカンヴァスではなく、オブジェなんですね。

 
Mihail Matkovskij:

チャートでも確認できたはずです。しかし、テスターでやった方が簡単だと思いました。

これは欠陥のあるアプローチです。特にビジュアルテスターは遅延レンダリングモデルが異なるので、テストプロセスを完全に遅らせることができないように。

ですから、おっしゃるとおり、OBJ_BITMAP_LABELの描画よりもラベルのテキスト描画の方が時間がかかるのです。

そうとは言っていない。

明らかな誤りを指摘し、レンダリングシステムの仕組みを説明しました。

1234567891011121314...18
新しいコメント