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

新しいコメント
 

ストラテジーテスター（特にビジュアルペンディングの特殊版）でグラフィカルな描画を テストするのは、作業チャートで直接やった方が良いのに、なぜでしょうか？

そして、非ビジュアルテスターでロボットのグラフィカルプロットを無効にすることを考えなかった人、おめでとうございます。

 

Nikolayの言う通り、ラベルのプロパティを編集することは、ラベルのレンダリングとは関係ないのです。

ラベルは、チャート上の他のオブジェクトと同様に、MQL5プログラムの作業とは全く別のスレッドで独立して描画されます。ロボットはチャートの強制再描画を依頼するのみで、描画時間を計測することはできない。オブジェクトを使ったチャート描画は完全に非同期です。

しかし、レンダリングキャンバスは、ロボットの流れの中で直接行われ、その後、チャートの独立したレンダリングの間に、ウィンドウのコンテキストで準備ができてビットマップのネイティブBitBlitを行うために残っているので、簡単に測定することができます。この操作は初歩的なもので、ビデオカードによってうまく加速されます。

テキストラベルでは、TTFフォントのSetFont/TextOutはかなり高価です。
 
Mihail Matkovskij:

この測定値を信じるなら、321倍であることが判明した。

この図から、この測定は信頼できないことがわかる。
これは、経験豊富なプログラマーにとっては当たり前のことである。
グラフィカルな画面に文字を表示するには、ピクセル単位で形成する以外に方法があるとお考えですか？ECockの時代はとっくに終わっているのです。
 
Renat Fatkhullin:

作業チャートで直接テストした方が良いのに、なぜストラテジーテスターで（特にビジュアルペンディングの特別バージョンで）グラフィカルプロットを テストしたいのでしょうか？

同時に、非ビジュアルテスターでロボットのグラフィカルプロットを無効にすることを考えなかった人たちは、おめでとうございます。

チャートでも確認できた。しかし、Strategy Testerの方がやりやすいと思ったのです。さらに、上記のように、CCanvas をベースにした表示では、テスターの Expert Advisor の動作が著しく遅くなる事態が発生したことがありました。特にダニに現れていました。チャートで示すには、テキスト出力はループで行う必要がある。つまり、現在制作中のオフライン最適化機能付きExpert Advisorで行っているように、より大きな更新レートを作るためです。そして、Canvasでは表示が遅くなってしまうので、ラベルベースの表示にすることにしたんです。なぜなら、ご指摘の通り、ラベルは別のスレッドでレンダリングされるので、私がループで動かしているEAの自律的最適化が遅くなることはありませんから。

おっしゃる通り、OBJ_BITMAP_LABELの描画よりもラベルのテキスト描画の方が時間がかかることが判明しました。そのため、高速化するためには、別スレッドでレンダリングする必要もあるのです。でも、どうやって？これができないと、OBJ_LABELを使う アプリケーションからすると、OBJ_BITMAP_LABELより 速いのですが・・・。

 
Nikolai Semko:
これは、経験豊富なプログラマーにとっては当たり前のことである。

詳しく勉強している、あるいは端末を知り尽くしている ベテランプログラマーにとっては、当たり前のことなのですまた、私はターミナルの開発者ではなく、ターミナルのアプリケーションを書くだけなので、他のプログラマーと同じように、MQLのドキュメントに書かれていないことはわからないかもしれません。

 
Mihail Matkovskij:

これは、詳しく勉強した、あるいは端末の操作を熟知して いる経験豊富なプログラマーなら、一目瞭然ですまた、私はターミナルの開発者ではなく、ターミナルのアプリケーションを書くだけなので、他のプログラマーと同じように、MQLのドキュメントに書かれていないことはわからないかもしれません。

それなのに、開発者だけでなく、MQのディレクターにも反論しようとしている。

 
Alexey Viktorov:

それなのに、開発者だけでなく、MQのディレクターにも反論しようとしている。

議論ではなく、使用するアプリケーションから見て、OBJ_BITMAP_LABELが OBJ_LABELよりもコストを低くすることができるかどうかを知りたいのです!

 
Mihail Matkovskij:

そして、Kanvasでは遅くなるので、ラベルベースの表示にすることにしました。


複数のフレームを30ミリ秒の1フレームに詰め込もうとしていたためです。
どうせフレームは毎秒30フレーム程度では再描画（ChartRedraw）されないということです。

ここで述べたように、kanvas テキストとラベルの違いは、ラベルの場合のピクセル配列の充填は非同期で、自分で制御できないので、ラベルの場合のピクセル配列の充填は約30ミリ秒に1回以上の頻度で行われないということです。
しかし、canvasでは非同期（ビットマップ充填）ではないため、起こる可能性があります。30ミリ秒の間に10回ビットマップを塗りつぶしても、表示されるのは1回だけで、9回はアイドル状態です。
そのため、『CANVASはカッコイイ！』で述べたように

動作のモデルとしては、以下のようなものが考えられます。

  • ビットマップを形成する関数が1つあります。
  • この関数の入力には、開始時刻がミリ秒単位で静的変数に格納されます。
  • 次にこの関数に入るときは、最後のビットマップ生成から30ミリ秒未満が経過しているかどうかを確認する必要があります。yes ならば終了して false を返し、no ならば - 新しい Bitmap への充填を開始し、出力します。
もちろん、bool変数をクラスに導入して、キャンバスの形成を許可するかしないかを指定する方が便利です。
 
Nikolai Semko:


複数のフレームを30ミリ秒の1フレームに詰め込もうとしたからです。
どうせフレームは毎秒30フレーム程度では再描画（ChartRedraw）されないということです。

ここで述べたように、kanvas テキストとラベルの違いは、ラベルの場合のピクセル配列の充填は非同期で、自分で制御できないので、ラベルの場合のピクセル配列の充填は約30ミリ秒に1回以上の頻度で行われないということです。
しかし、canvasでは非同期（ビットマップ充填）ではないため、起こる可能性があります。30ミリ秒の間に10回ビットマップを塗りつぶしても、表示されるのは1回だけで、9回はアイドル状態です。
そのため、『CANVASはかっこいい！』で述べたように

動作のモデルとしては、以下のようなものが考えられます。

  • ビットマップを形成する関数が1つあります。
  • この関数の入力には、画像生成の開始時刻がミリ秒単位で静的変数に格納される。
  • 次にこの関数に入るときは、最後のビットマップ生成から30ミリ秒未満が経過しているかどうかを確認する必要があります。yes の場合は終了して false を返し、no の場合は新しい Bitmap の塗りつぶしと出力に進みます。
キャンバスを作成するクラスで変数を導入するのがよいかもしれません。

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

 

このスクリプトの基本は、こちらの ドキュメントから引用しています。
100回100行を出力するランダム配列から始まり、100枚のラベルを生成します。
まず、Labelで100フレームを出力する。
その後、100フレームをキャンバス文字列で出力します。
キャンバスは同じものです。
イン・ア・ループSleepは 文書化されています。ループにSleep(0)が含まれている場合、状況はかなり違ってきます。少し実験してみてもいいかもしれませんね。
すべてのフレームとラインには、管理のために番号が付けられています。
動画を撮影し、30回ほどスロー再生したことがあります。100枚のうち、実際にラベルがレンダリングされたのは2枚だけで、しかも2枚目のフレームでは、ラベルが異なるフレームのものであること、つまり非同期性が働いていることがわかると思います。



一方、Kanvasは100フレーム中60～70フレーム程度を出力しています。これは、30ミリ秒より少し早くフレームが形成されるため、すべてのフレームが形成されるにもかかわらず、出力される時間がないために起こったことである。上位2つのパラメータ 、サイクルディレイを実験してください。




出力する行数を増やすと、エラー4001が発生する場合があります。これは、出力が多すぎる場合のMQのバグです。

ファイル:
CanvasVsLabel.mq5  19 kb
12345678910111213...18
新しいコメント