MQLで書かれたUIのギャラリー - ページ 53

[hini]

Реterさん、今後のリリースではディレクトリを英語に変更することを検討していただけますか？カタログ名を含むソースコードファイルはテキスト置換で行っています。

[Реter Konow]

hini #:
Retherさん、今後のリリースでカタログを英語に変更することを検討していただけませんか？カタログ名を含むソースコードファイルはテキストに置き換えられます。

はい、もちろんです。すでに考えています。カタログ名を英語にした特別リリース版を作るつもりだ。

[Samuel Manoel De Souza]

私はファイルをチェックしていません。しかし、私にとっての「ラグ」はスピードとは関係なく、新しいリソースを完全に作成する前にChartRedrawを使用することにあるようです。というのも、真っ白なキャンバスでまばたきしてから、新しいキャンバスを表示するからです。

[hini]

Реter Konow #:

もちろんだ。少し考えてみた。英語のカタログ名を入れた特別リリースを作るよ。

私の提案としては、英語のディレクトリを含む特別なリリースを用意するのではなく、これら1つの英語リリースのうちの1つだけを用意し、ディレクトリ名を英語に変更するだけで、次のステップはファイル名を英語に変更し、ソースコードはロシア語のまま書くというものだ。

少なくとも、そのコードを見る他の人たちは、ファイル名を見るだけで、おそらく何をしているのか理解できるだろう。

[Реter Konow]

hini #:
英語のカタログで特別なリリースをするのではなく、そのような英語のリリースを1つだけ作り、カタログの名前を英語に変えるだけで、次のステップはファイル名を英語に変えるだけで、ソースコードはロシア語のまま書くことを提案したい。

少なくとも、コードを見る私たち以外は、ファイル名を見るだけで、おそらく何をしているのかがわかるだろう。

そうだね。私は徐々にディレクトリ名を英語表記に切り替えるつもりだ。その方が合理的だ。

[Реter Konow]

Samuel Manoel De Souza #:

私はファイルをチェックしていません。しかし、この "ラグ "はスピードとは関係なく、新しいリソースが完全に作成される前にChartRedrawを使用することに起因しているようです。というのも、空白のキャンバスが点滅し、その後新しいキャンバスが表示されるからです。

面白いアイデアですね、試してみます。ありがとう。

[Реter Konow]

というわけで、近況報告。

これは中間アップデートです。数日中に次のバージョンをリリースする予定だ。コントロールと プログラムの相互作用に関する新しい機能が追加される予定だ。

私は2470と新しい2つのビルドで仕事をしている。ほとんどの開発は古いビルドで行っている。コンパイルは旧ビルドの方が速く、26～32秒に対して4秒だ。新しいビルドは少し動作が違っていて、見た目でもわかる。速くなることもあれば、遅くなることもある。そう感じるだけかもしれない。違いを見つけるのは難しいが、私にはそれがあるように思える。古いビルドのインターフェイスは飛んでいる。新しいものでは。ほとんど飛ぶ。慣れているからかもしれない。

しかし、ニュアンスの違いはある。例えば、チャートの切り替えで、チャートの高さと幅が正しくない値が返される問題がある。これはタスクバーをジャンプさせてしまう。この問題を回避することに成功したが、その後、タスクバーはチャートのサイズ変更の他のイベントには反応しなくなった。結局、そのままにしておくことにした。不正確な値を返すという問題がある限り）チャートの切り替え時にタスクバーはジャンプするが、他のイベントでは正常に適応する。

しかし、それだけではない。チャートのサイズ変更のイベントは即座には発生せず、半秒の間があることがわかった。この遅延がタスクバーの再描画時間に重なり、それなりのラグが発生する。ここで私は無力である。

もちろん、グラフィックを大幅に高速化しましたが、コードにはまだ他にも最適化されていない解決策があります。私はそれらに懸命に取り組んでいる。主にウィンドウのフォーカス遷移と再描画キューに関するものだ。不必要な呼び出しもあります。タスクバーの遅延。すべてではないが、修正する時間があったものは修正した。しかし、残りは数日後の問題だ。そうでなければ、特に改善すべき点はない。多分、コードを櫛で梳いて香りをつけるくらいだろう））。

一般的には、残っている最適化されていない解決策をすべてデバッグすれば、飛べるだろう...。もちろん、MQLプログラムで利用可能なスピードの範囲内で。

リリースをご覧ください。

[Реter Konow]

Реter Konow #:

それで、近況報告だが...。

...

こう言っておこう：グラフィックはもちろん大幅に高速化したが、コードにはまだ最適化されていない解決策がある。私はそれらに懸命に取り組んでいる。主にウィンドウのフォーカス遷移と再描画キューに関するものだ。不必要な呼び出しもあります。タスクバーの遅延。すべてではないが、修正する時間があったものは修正した。しかし、残りは数日後の問題だ。そうでなければ、特に改善すべき点はない。多分、コードを櫛で梳いて香りをつけるだけだろう））。

一般的には、残っている最適化されていない解決策をすべてデバッグすれば...。もちろん、MQLプログラムで利用可能な速度の範囲内ではあるが。

リリースをご覧ください。

はっきりさせておくが、ここではスピードについて話している のだ。フォーカス・チェンジ・イベントでウィンドウが再描画される欠点を修正すれば、インターフェイスの速度はMQLプログラムの上限に達するだろう。タスクバーの遅延は部分的に修正できる。タスクバーのメカニズムにダイナミック・ウィンドウの原理を応用することだ。そうすれば、より速く、より気づかれないように調整できる。そしてもちろん、不要な再描画をキャンセルする必要がある。これは必須だ。しかし、CHARTEVENT_CHART_CHANGEイベント自体が遅延してプログラムにやってくるのであれば、タスクバーの反応の目に見える遅延は、それとは関係ないが避けられない。

そうでなければ、インターフェイスの開発や改良の方向性はたくさんある。

[Реter Konow]

インターフェイスのスピードについてもう少し。

私は遅延のチェックとレンダリングブレーキの探索に多くの時間を費やしました。カンヴァスのレイアウトを担当するブロックは、ResourceCreate() 関数でリソースを作成 する配列を初期化する前に、ウィンドウの詳細に関するループの境界を定義するように構築されています。これは、入ってくるイベントをチェックするように設定された条件フィルタの助けを借りて行います。ブロックを呼び出す各イベントには、描画の境界が与えられます。例えば、カーソルがホバーされたときの要素の反応のイベントでは、特定の要素の詳細でのみループの境界を持つフィルタが有効になります。このブロックは、撮影された画像上でその詳細のみを選択します。そして、細部のサイクルの間に、残りの画像の中からその細部だけを選択的に描画する。これは、正しい要素の正しいディテールを初期化し描画する場所を正確に見つけます。同時に、残りの画像空間を正しくバイパスする。

しかし、加速はそれだけではない。このブロックは、キャンバスの点の色が必要な値に一致する場合、その点を初期化しません。また、配列の中を「走る」のではなく、「ジャンプ」して距離を飛び越える。これにより、何十万回もの反復が削減される。

それだけではない。画像配列はグローバルなので（グローバル・レベルで宣言される）、常に最後の画像の変更をメモリに保存する。そして、同じキャンバス上で変更が続くと、そのたびに配列をクリアするのではなく、保存されている画像が使用されます。次のイベントでリソース名が変更されなければ、ResourceReadImage() を呼び出す必要はありません。このブロックは、ResourceReadImage() を呼び出さずに 残りのデータで処理を続け、変更後に ResourceCreate() で画像を更新します。

これにより、ResourceReadImage() を呼び出す時間を大幅に節約できます。また、配列をクリアしたり埋めたりする時間も節約できます。グローバル・メモリの有効利用ですね。

ウィンドウを再描画するときは、このブロックはまったく呼び出されません。ウィンドウのコンポーネントは消去され、作成され、以前に保存されたリソースがそれらにアタッチされます。レンダリングはない。

これだけやってもラグが発生するのは避けられない。何が起こっているのか説明しよう。

ウィンドウを最初に開いたとき、タブを最初に開いたとき、ツリーリストを開いたとき、大きなスペースを最小化／非モデリングしたとき、キャンバスの完全な再描画が必須 です。後で何度も効率的にリンク/変更できる画像リソースを作成する瞬間まで、必ず1回はゼロから完全な画像を描画する必要があります。最初の描画は常に最長である。保存するものは何もないし、保存された画像もない。ラグが発生するのは、最初に開いたときです。それは避けられない。

しかし、ここにも良い解決策がある。ウィンドウを開くときのラグをローディング・イベントに移動させるのだ。つまり、バックグラウンドでコンストラクタをロードする段階で、すべての画像を描画し、あらかじめリソースに保存しておくのだ。そうすれば、初めてウィンドウを開くときに、ユーザーは遅延を感じることはない。これはもちろん素晴らしいことだが、欠点もある。最初にウィンドウを開くときの遅れは、ローディングの遅れに変わり、その時間は長くなる。どの程度かはわからない。平均して1秒以内だと思う。特定のインターフェイスによる

私はこのオプションが望ましいと思います。デザイナー／ユーザーインターフェイスのロード時間は少し長くなりますが、視覚的なオープニングの遅れはなくなりますから。

これについてのあなたの意見に興味があります。

追加しました：

最初のロード後にインターフェイスのリソースをファイルに保存するアイデアがありました。 そうすれば、必要なリソースはすでにデザイナーやエンジンが自由に使える状態になっているので、その後のロードはずっと速く なります。検討する必要がある。

[Nikolai Semko]

何かおかしいよ、ピーター。

1秒のラグというのは法外なラグだ。ウィンドウ全体の最もトリッキーなインターフェースの形成は、50ミリ秒を超えてはならない。

レンダリングロジックがUpdate関数（実際にはChartRedraw）でオーバーロードされているように見える。

この仮定を確認するには、CCanvas クラス（使用している場合）の Update 関数に静的カウンタを置き、たとえば count%100 == 0 のときにこのカウンタを表示します。