MT5ターミナルでインジケーター(ライン、矢印、ヒストグラム)が点滅するのはなぜですか? - ページ 9

 
Andrey Khatimlianskii: プロセッサーに大きな負荷がかかるとフリッカーが再現されやすくなります。すべてのローカルコアで 最適化を実行 し、十数個のオブジェクトを削除/作成し、ChartRedrowを実行してみてください。スワッグ効果は確実です。

でも、フリッカーを再現するのではなく、フリッカーを止める、このフリッカーが見えなくなるような工夫をしたいですね。
また、プロセッサがロードされていない良い状態では、アイドル状態と言ってもよく、最適化は実行されず、つまりローカルコアもロードされず、オブジェクトは作成されず、ChartRedraw()は呼び出されません。そして、この静謐なPCの中で、「ガーランド」は点滅を続けているのだ!

開発者も答えてくれないし、この点滅は回復不可能でMT5の将来のバージョンでのみ解消されるのか、それともインジケータ開発者の手が間違っていてMT5用のインジケータ開発時に何か理解できていないのか・・・。

 

カスタムインディケーターだけ でなく、「リグレッションチャンネル」などの内蔵ツールも点滅します。

 

Aleksey Vyazmikin: Мерцают не только пользовательские индикаторы, но и встроенные инструменты, к примеру "Канал регрессии".

もしそうなら、推測することは何もありません。この問題はまだ原理的に解決できず、MT5の将来のバージョンで解決されることを意味します。開発者はそれを正直に伝えるべきで、プログラマーに何が間違っているのか、どう対処すればいいのか、頭を悩ませる必要はないのでは...。

 

2日ほど前から悩んでいたんです。

上記でアドバイスされたことはすべて試しました。

役に立たなかった。

MT5でインジケーターがチカチカするのは、この理由だけです。

ChartGetInteger(0,CHART_VISIBLE_BARS ...) を適用した場合。

少なくとも、この関数の代わりに定数を設定すると、ちらつきがなくなりました。

ちょっと応用が利かなかったかもしれませんが、それでも......。
Документация по MQL5: Операции с графиками / ChartGetInteger
Документация по MQL5: Операции с графиками / ChartGetInteger
  • www.mql5.com
Возвращает значение соответствующего свойства указанного графика. Свойство графика должно быть типов datetime, int или bool. Существует 2 варианта функции. 2. Возвращает true или false в зависимости от успешности выполнения функции.  В случае успеха значение свойства помещается в приемную переменную, передаваемую по ссылке последним параметром...
 

それも役に立たなかった ;)))

 
Renat Akhtyamov:

それも役に立たなかった ;)))

" ...この関数は同期式です。つまり、タイムテーブルのキューに入れられたすべてのコマンドが呼び出されるまで待ちます ..."

これはドキュメントからです。同期関数はプロセス全体を遅くします。その関数の実行が終了するまでは、たとえその関数の実行に利用できるリソースがあったとしても、他のプロセスは実行を開始しません。

 
フリッカーはターミナルエンジンによるオブジェクトの再描画に依存するという仮説があります。つまり、プロットポイントが可視画面の外にある場合、レンダリングの優先度は低くなり、それがグラフの計算負荷(見積もり到着率も含む-強く激しい動きでフリッカーが発生することに気づきました)に現れているのです。
 
Aleksey Vyazmikin:
フリッカーはターミナルエンジンによるオブジェクトの再描画に依存するという仮説があります。つまり、プロットポイントが可視画面の外にある場合、レンダリングの優先度は低くなり、それがチャートの計算負荷(見積もり到着率も含む-強く激しい動きでフリッカーが発生することに気づきました)の間に現れるのです。

開発者の方々には、ぜひこの話題に注目してほしいですね。

インジケーターのチラツキは、それだけでは解消できません。

 

わかったような気がします。

無きにしもあらず

は、現在リアル口座で取引されている現行EAの外部テストのようなものだと思われます。

私の個人的な結論は、次のとおりです。

チャートは正確に10時間前に構築され、我々は既製のものを見ている

あとは、右側の舞台裏で、徐々にスクリーンに映し出されていきます。

私は、飛びつかないように、ビデオを録画しましたが、ここではなく、人々が非常に興味を持つであろう、あちらでお見せしたいと思います。

---

画中

まず、小節の数が変わります。1000本と決まっていますが、ゼロから計算するので、1001本となるのです。

フリックした瞬間に突然バーが600本少なくなる(フリック時は常に358本と同じ)。

と表示される瞬間が時々あります(ビデオでは何とかフレームを捕らえることができました)。

そして、最も興味深いのは、時々、ちらつきの瞬間に、現在から未来へ、すなわち、彼らはちょうど今のところ開いている、とどこかがそこに閉じられるだろうから、グラフィカルに閉じた取引を示して います - 背後には

自分の目ですべてを確認するには、最後のバーだけでなく、すべてのバーを再計算し、すべてのティックで、各計算の前にバッファをクリーニングします。

あ、そうだ、忘れてた。

よのなかのこと

私の友人の調査員がすべての資料を持ち帰ったのですが、かなりイケていると言っていました;)

;))))

----

ということで、議論になります.

 
Aleksey Vyazmikin:
フリッカーはターミナルエンジンによるオブジェクトの再描画に依存するという仮説があります。つまり、プロットポイントが可視スクリーンの外にある場合、レンダリングの優先度は低くなり、チャート上の計算負荷(引用の速度を含む - 私は強く激しい動きのときにフリッカーが発生することに気づきました)に表示されるのです。

アラ・ユリエヴナが言ったように、馬には明らかだった。コンポスターは、間接的ではありますが、その原因を示しています。端末に負荷がかかるとフリッカーが発生する、これは事実です。過負荷は様々な理由で発生しますが、必ずしも端末の演算能力を超えるとは限りません。