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

[Реter Konow]

Nikolai Semko #:
パースはない。テキストやシャドウなどを駆使したインターフェイスは、弱いプロセッサーでは最大50msだ。

バグを探せ。

プロファイリングを実行してください。どの関数が95%の時間を食っているか見てください。

もしかしたら、ChartGetやXY関数を使用しているかもしれません（チャートへのバインディングはありませんが）。

とにかくプロファイリングを実行してください。たった40秒しかかからない。

ああ、もう一度全部チェックするよ。でも、問題はそこじゃない。描画ブロックはただ描画するだけではない。その内部には、入ってくるイベントを処理する論理的な迷路がある。何を描き、何を描かないかを決めるために必要なのだ。どこから画像を取り込み、どこにどのように重ねるかを選択する。100本の線を引くだけの単純な描画機能なら言うことはない。しかし、これはあらゆるものを確実に描くための大規模なメカニズムなのだ。

それは考慮に値する))

[Реter Konow]

Andrey Barinov #:

ただ、純正のキャンバスは使っていない んだ。）

...

そして、これは嬉しい驚きだ。:)自己啓発はいつもクールだ。たとえ不完全でも。

Ccanvasクラスは嫌いではない（コンストラクタ・ファイルにその機能を含めたくらいだ）が、まだ使っていない。キーワードは "まだ "だ。大きな計画があるんだ。将来的には。

[Реter Konow]

チャートと同じ大きさの真っ白なグリーン・キャンバスのレンダリング速度をチェックして、ここに掲載します。

[Nikolai Semko]

Реter Konow #:

ああ、すべてダブルチェックするよ。でも、問題はそこじゃない。ドローイングブロックはただ描くだけではない。その内部には、入ってくるイベントを処理する論理的な迷宮がある。何を描き、何を描かないかを決めるために必要なのだ。どこから画像を取り込み、どこにどのように重ねるかを選択する。100本の線を引くだけの単純な描画機能なら言うことはない。しかし、これはあらゆるものを確実に描画するための大規模なメカニズムなのだ。

それは考慮に値する))

いや、正しく実装されていれば、たとえ何千ものチェックがあったとしても、イベントモデルに1マイクロ秒（100万分の1秒）以上かかることはない。

バグを探しなさい。

そして守りに入るのはやめなさい！誰もあなたを攻撃しているわけではない。

私は10万個のオブジェクトで顕著なラグ（300ミリ秒以上）が始まり、価格時間と結びついている。

[Реter Konow]

Nikolai Semko #:
いや、正しく実装されていれば、たとえ何千ものチェックがあったとしても、イベントモデルに1マイクロ秒（100万分の1秒）以上かかることはない。

バグを探しましょう。

そして守りに入るのはやめなさい！誰もあなたを攻撃しているわけではない。

私は100,000のオブジェクトで顕著なラグ（> 300ミリ秒）が開始され、価格-時間に結びついている。

守りに入っているわけではありません。）ははは。ただ説明しているだけです。))

オーケー。簡単なテストから始めよう。1つのフルスクリーンキャンバスを1つの色で塗りつぶして、時間を測る。あなたのレンダリング機能を測定すれば、私のコードにブレーキがあるかどうかが明らかになるでしょう。あるかもしれない。議論しているわけではない。チェックが必要なんだ。

[Nikolai Semko]

Реter Konow #:

守りに入っているわけではないよ（笑)。ハハハ。ただ説明しているだけだ。))

オーケー。簡単なテストから始めよう。1つの全画面キャンバスを1つの色で塗りつぶして、時間を測定します。あなたのレンダリング機能を測定すれば、私のコードにブレーキがあるかどうかが明らかになるでしょう。あるかもしれない。議論しているわけではない。チェックが必要なんだ。

あなたはプロファイリングをしたことがないのでは？あなたはデバッグの仕事もしていない。

[Реter Konow]

Nikolai Semko #:

プロファイリングをやったことがないのかと思った。デバッグもやったことがないんだろう。

デバッグはしない。ロシアのコードのせいでできないんだ。プロファイリングはやったことがある。でもずいぶん昔のことだ。私は昔ながらの方法でコーディングするのが好きなんだ。そういうものなんだ。

明日はやるよ。ここ数日、朝6時から夜10時、11時まで仕事をしている。オンとオフ。ちょっと疲れたよ。

[hini]

スピードはおそらく後回しにできるし、スピードの最適化はすぐにできるものではない。

[Реter Konow]

hini #:
スピードはおそらく後景に追いやられるし、スピードの最適化はすぐにできるものではない。

まあ、スピードを向上させるのはコーダーにとって常にいいことだ。そして一般的には、私もそう思う。合理的だ。開発における適切な優先順位付けはとても重要だ。特にこのような大きなプロジェクトではね。ユーザーにとってスピードがどの程度重要なのかを知ることは僕にとって重要だった。いわば、フィードバックを得るためにね。それ自体でのスピードアップは、私の当初の計画には含まれていなかった。ただ、ユーザーがインターフェイスを見るときに、ラグでヒヤヒヤしないようにしたかっただけなんだ。:)

もちろん、エレメントの機能性が最優先であることに変わりはない。エンジン、エレメント、バグ。それがメインだ。

[Реter Konow]

ニコライ・ セムコ

ニコライ、「なぜ キャンバスを描くのにこんなに時間が かかるのか」という質問に対する答えが思いがけず出てきたよ。

窓は2枚のキャンバスで 構成されている！ このキャンバスの大きさはほぼ等しい。だから描画面積は2倍になるはずだ。しかし、それは始まりに過ぎない。

ウィンドウのスペースには大きなスクロール要素（V_BOX）があり、これも元の色で完全に塗りつぶされて描画される。つまり、V_BOXがウィンドウの主要部分を占めると、描画領域は3倍になるはずだ。しかし！これは追加のキャンバスを持っている。画像はそのキャンバス上でスクロールされる。要素のベースはスクロールバーだけです。要するに、描画領域は4倍になるはずだ（特にスクロールバーが長い場合）。 そして、そのときだけ要素が描画される。

これで終わりかと思いきや......。 ウィンドウの面積を3倍か4倍に すればいいのだ。 しかし、そうではない！

エレメント自体も多層構造 になっている。それぞれにベースがある。ベースは常に ゼロから描かれ、元の色で塗りつぶされる。 その上にフレームが描かれる。次に、アイコンがすでに描かれている部分の上に描かれます。そして最後に、テキストがすべての上に描かれる。

その結果、ユーザーは各ピクセルの最終的な色だけを見ることになる。 しかし、このピクセルの場所では、ウィンドウ全体が描画されるにつれて色が何度か変化する。

これを15個のウィンドウに当てはめてみると......。描画ブロックの一部の実行速度を特別に測定してみたが、フルスクリーンで50ミリ秒というのは私にも有効 だった。ただ、画面数が多くなってしまいます。

コードを変更して、描画を2～3倍速くする方法は考えています。 でも、メインの仕事が終わってからやるつもりだ。

コードのチェックにこだわってくれてありがとう。君の言う通りだ。批評が役に立った。

また、テキストのヒントを くれた アンドレイ・バリノフにも 感謝する。何か思いつくかもしれない。