Canvasでクラウドソーシングのプロジェクトを作る - ページ 32 1...252627282930313233343536373839...45 新しいコメント Реter Konow 2020.01.26 11:13 #311 Алексей Барбашин: まさにその通りに作りました。標準ライブラリは、イベント転送の瞬間やその他が非常によくできているので、原則的にこれをベースにしました。アナトリーは、異なるクラスの要素ごとにグループ化を行い、標準的なものでは、すべてを1つの基本オブジェクトに還元しています。 ... 彼の例では、キャンバス全体の再描画は非常に高速なので、細部まで描き込む必要はなく、キャンバス全体を一度に再描画すれば十分なので、ローカルエリアのデータをすべて保存する必要はないことを説明しています。 そんな簡単なものではありません。大きな（フルサイズの）表があり、その中の1つのセルの値が1秒間に20回変化すると想像してください。キャンバス全体を再描画した場合、プロセッサの負荷は最大で40％以上増加します。キャンバスの扱い方は絶対に間違っている。別々の要素を再描画する必要があります。そうしないと、テーブル、ガラス、およびさまざまなローカルアニメーションがプロセッサに負荷をかけ、他の機能の実行が遅くなります（それらが共通のスレッドにある場合）。 Алексей Барбашин 2020.01.26 12:27 #312 Реter Konow: そんな簡単なものではありません。大きな（グラフ全体の）表を描いたとして、その中の1つのセルの値が1秒間に20回変化するとします。キャンバス全体を再描画した場合、プロセッサの負荷は最大で40％以上増加します。キャンバスの扱い方は絶対に間違っている。別々の要素を再描画する必要があります。そうしないと、テーブル、ガラス、および異なるローカルアニメーションがプロセッサに負荷をかけ、他の機能の実行が遅くなります（それらが共通のスレッドにある場合）。 ニコライのこれまでの実験は、その逆を証明している。キャンバスの中身を一気に再描画しているのですが、その様子がコードにはっきりと表れています。 でも、やはりローカルチェンジには賛成です。しかし、この方法には難点があり、私はまだ解決できていません。 Реter Konow 2020.01.26 12:40 #313 Алексей Барбашин: ニコライのこれまでの実験は、その逆を証明している。キャンバスの中身を一気に再描画しているのですが、その様子がコードにはっきりと表れています。 でも、やはりローカルチェンジには賛成です。しかし、この方法には、まだ解決していない困難があります。 私はニコライを友人だと思っています。彼はキャンバスを使った仕事で大きな高みに到達しましたが、まだ本格的な制御の実験はしていません。特にテーブルとガラスで。とりあえず、意識はしていない。 要は、こういうことです。キャンバスは、データの配列です。変更イベント時にデータを変更し、再保存する。配列がチャート空間のすべてのピクセルを含む場合、そのサイズ =チャートの高さ*幅と なります。配列内の画素値が局所的に変化した場合、配列全体をフルループしてすべての値をリセットする必要はありません。変更した領域でループを行い、値を設定し、ループを抜ける必要があります。そうでなければ、どう考えても、資源と時間の無駄です。 そして、この方法には多くの困難があります。主なものは、自分のキャンバスの上で、完全に機能するオブジェクトを自分で作り、それを見つけて加工することです。 インハウスのCCanvasはそれに適していません。それはあなたの要素を「見る」ことはできないだろうし、それを使って処理することもできない。そこには、そのような機能はありません。 Алексей Барбашин 2020.01.26 12:43 #314 Реter Konow: 私はニコライを友人だと思っています。彼はkanvasで高みを目指していますが、まだ本格的な制御の実験をしていません。特にテーブルとタンブラーで。とりあえず、意識はしていない。 要は、こういうことです。キャンバスは、データの配列です。変更イベント時にデータを変更し、再保存する。配列がチャート空間のすべてのピクセルを含む場合、そのサイズ =チャートの高さ*幅と なります。配列内の画素値が局所的に変化した場合、配列全体をフルループしてすべての値をリセットする必要はありません。変更した領域でループを行い、値を設定し、ループを抜ける必要があります。 そうでなければ、どう考えても、資源と時間の無駄です。 そして、この方法には多くの困難があります。主なものは、自分のキャンバスの上で、完全に機能するオブジェクトを自分で作り、それを見つけて加工することです。インハウスのCCanvasはそれに適していません。それはあなたのエレメントを「見る」ことはできないし、それを通してエレメントにアクセスすることもできないでしょう。そこには、そのような機能はありません。 私はこのことをよく理解していますし、よく承知しています。独自にオブジェクトクラスを作成し、すべて正常に動作しています。 Реter Konow 2020.01.26 12:48 #315 Алексей Барбашин:すべてよく理解し、自覚しています。オブジェクトクラスが作成され、すべて正常に動作しています。 この場合、表を作成 し、ローカルに（各セルごとに）更新する方法と、表全体を一括して更新する方法の2通りで確認することができます。 Реter Konow 2020.01.26 13:18 #316 ニコライのアニメーションはリフレッシュレートが低いものが多いので、キャンバス全体を同時に再描画してもオーバーラップとして出てこないんです。しかし、リフレッシュレートを1秒間に5回まで上げると、CPUリソースの消費量が増加することがわかります。アニメーション全体を描き直す必要がある場合は仕方ありませんが、内部の小さなエリア1つだけなら、その1つだけで良いのです。 1秒間に5回という頻度自体は、値が非同期に変化するテーブルで発生する可能性があります。MT4で、テーブルをリソース経由でテスターに接続すると、このような状況が発生しました。そこでは、速度31ですべてのパラメータが高速に変化するため、テーブルの再描画を誤ると50％以上のCPU負荷が発生しました。要素のローカル再描画でも、完全に保存することはできませんでした。そこで思いついたのが、数値の表示速度を遅くすることでした。値そのものは自然な速度で変化しているのに、セルへの出力は数倍も頻度が低い。これで問題は解決した。 以下はその一例です。1000個のセルが25msの割合で値を変化させること。実際には、500msに1回程度セルの値が変わり、CPUの負荷は50％程度です。(MT4で、表が描かれています）。 https://www.mql5.com/ru/forum/293630/page160 テスターを使った例です。表は描画されるが、プロセッサの過負荷を軽減することはできない。:)(テスター速度31、セル更新フル(ピンスキップなし))。 https://www.mql5.com/ru/forum/293630/page148 Алексей Барбашин 2020.01.26 13:31 #317 Реter Konow: そんな単純な話じゃないんです。大きな（チャート全体の）表があり、その中の1つのセルの値が1秒間に20回変化すると想像してください。キャンバス全体を再描画した場合、プロセッサの負荷は最大で40％以上増加します。キャンバスの扱い方は絶対に間違っている。別々の要素を再描画する必要があります。そうしないと、テーブル、ガラス、および異なるローカルアニメーションがプロセッサに負荷をかけ、他の機能の実行が遅くなります（それらが共通のスレッドにある場合）。 どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。速度低下は全くありません。 Canvas - это круто! 2019.09.20www.mql5.com Поставил себе задачу: коротким кодом эффектно продемонстрировать возможности пользовательской графики через класс CCanvas... Реter Konow 2020.01.26 13:36 #318 Алексей Барбашин: どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。 動作が遅くなることはありません。 上の例を見てください。 ハイファへのリンクを挿入しました。 Реter Konow 2020.01.26 13:44 #319 ここでは、セルへの値の出力を遅くし、プロセッサの負荷を軽減する例を紹介します。 https://www.mql5.com/ru/forum/293630/page148 Реter Konow 2020.01.26 13:47 #320 Алексей Барбашин: どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。 速度低下は全くありません。 その例のリフレッシュレートは正常です。したがって、減速することはありません。 1...252627282930313233343536373839...45 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
まさにその通りに作りました。標準ライブラリは、イベント転送の瞬間やその他が非常によくできているので、原則的にこれをベースにしました。アナトリーは、異なるクラスの要素ごとにグループ化を行い、標準的なものでは、すべてを1つの基本オブジェクトに還元しています。
...
彼の例では、キャンバス全体の再描画は非常に高速なので、細部まで描き込む必要はなく、キャンバス全体を一度に再描画すれば十分なので、ローカルエリアのデータをすべて保存する必要はないことを説明しています。そんな簡単なものではありません。大きな（グラフ全体の）表を描いたとして、その中の1つのセルの値が1秒間に20回変化するとします。キャンバス全体を再描画した場合、プロセッサの負荷は最大で40％以上増加します。キャンバスの扱い方は絶対に間違っている。別々の要素を再描画する必要があります。そうしないと、テーブル、ガラス、および異なるローカルアニメーションがプロセッサに負荷をかけ、他の機能の実行が遅くなります（それらが共通のスレッドにある場合）。
ニコライのこれまでの実験は、その逆を証明している。キャンバスの中身を一気に再描画しているのですが、その様子がコードにはっきりと表れています。
でも、やはりローカルチェンジには賛成です。しかし、この方法には難点があり、私はまだ解決できていません。
ニコライのこれまでの実験は、その逆を証明している。キャンバスの中身を一気に再描画しているのですが、その様子がコードにはっきりと表れています。
でも、やはりローカルチェンジには賛成です。しかし、この方法には、まだ解決していない困難があります。
私はニコライを友人だと思っています。彼はキャンバスを使った仕事で大きな高みに到達しましたが、まだ本格的な制御の実験はしていません。特にテーブルとガラスで。とりあえず、意識はしていない。
要は、こういうことです。キャンバスは、データの配列です。変更イベント時にデータを変更し、再保存する。配列がチャート空間のすべてのピクセルを含む場合、そのサイズ =チャートの高さ*幅と なります。配列内の画素値が局所的に変化した場合、配列全体をフルループしてすべての値をリセットする必要はありません。変更した領域でループを行い、値を設定し、ループを抜ける必要があります。そうでなければ、どう考えても、資源と時間の無駄です。
そして、この方法には多くの困難があります。主なものは、自分のキャンバスの上で、完全に機能するオブジェクトを自分で作り、それを見つけて加工することです。 インハウスのCCanvasはそれに適していません。それはあなたの要素を「見る」ことはできないだろうし、それを使って処理することもできない。そこには、そのような機能はありません。
私はニコライを友人だと思っています。彼はkanvasで高みを目指していますが、まだ本格的な制御の実験をしていません。特にテーブルとタンブラーで。とりあえず、意識はしていない。
要は、こういうことです。キャンバスは、データの配列です。変更イベント時にデータを変更し、再保存する。配列がチャート空間のすべてのピクセルを含む場合、そのサイズ =チャートの高さ*幅と なります。配列内の画素値が局所的に変化した場合、配列全体をフルループしてすべての値をリセットする必要はありません。変更した領域でループを行い、値を設定し、ループを抜ける必要があります。 そうでなければ、どう考えても、資源と時間の無駄です。
そして、この方法には多くの困難があります。主なものは、自分のキャンバスの上で、完全に機能するオブジェクトを自分で作り、それを見つけて加工することです。インハウスのCCanvasはそれに適していません。それはあなたのエレメントを「見る」ことはできないし、それを通してエレメントにアクセスすることもできないでしょう。そこには、そのような機能はありません。
私はこのことをよく理解していますし、よく承知しています。独自にオブジェクトクラスを作成し、すべて正常に動作しています。
すべてよく理解し、自覚しています。オブジェクトクラスが作成され、すべて正常に動作しています。
この場合、表を作成 し、ローカルに（各セルごとに）更新する方法と、表全体を一括して更新する方法の2通りで確認することができます。
ニコライのアニメーションはリフレッシュレートが低いものが多いので、キャンバス全体を同時に再描画してもオーバーラップとして出てこないんです。しかし、リフレッシュレートを1秒間に5回まで上げると、CPUリソースの消費量が増加することがわかります。アニメーション全体を描き直す必要がある場合は仕方ありませんが、内部の小さなエリア1つだけなら、その1つだけで良いのです。
1秒間に5回という頻度自体は、値が非同期に変化するテーブルで発生する可能性があります。MT4で、テーブルをリソース経由でテスターに接続すると、このような状況が発生しました。そこでは、速度31ですべてのパラメータが高速に変化するため、テーブルの再描画を誤ると50％以上のCPU負荷が発生しました。要素のローカル再描画でも、完全に保存することはできませんでした。そこで思いついたのが、数値の表示速度を遅くすることでした。値そのものは自然な速度で変化しているのに、セルへの出力は数倍も頻度が低い。これで問題は解決した。
以下はその一例です。1000個のセルが25msの割合で値を変化させること。実際には、500msに1回程度セルの値が変わり、CPUの負荷は50％程度です。(MT4で、表が描かれています）。
https://www.mql5.com/ru/forum/293630/page160
テスターを使った例です。表は描画されるが、プロセッサの過負荷を軽減することはできない。:)(テスター速度31、セル更新フル(ピンスキップなし))。
https://www.mql5.com/ru/forum/293630/page148
そんな単純な話じゃないんです。大きな（チャート全体の）表があり、その中の1つのセルの値が1秒間に20回変化すると想像してください。キャンバス全体を再描画した場合、プロセッサの負荷は最大で40％以上増加します。キャンバスの扱い方は絶対に間違っている。別々の要素を再描画する必要があります。そうしないと、テーブル、ガラス、および異なるローカルアニメーションがプロセッサに負荷をかけ、他の機能の実行が遅くなります（それらが共通のスレッドにある場合）。
どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。速度低下は全くありません。
どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。 動作が遅くなることはありません。
上の例を見てください。
ハイファへのリンクを挿入しました。ここでは、セルへの値の出力を遅くし、プロセッサの負荷を軽減する例を紹介します。
https://www.mql5.com/ru/forum/293630/page148
どこから数字を出しているのか、よくわからない。ニコライの完璧にシンプルな例を見てくださいhttps://www.mql5.com/ru/forum/227736/page44#comment_13445909。グラフサイズのキャンバス上に、複数のオブジェクトが生成され、グラフ上（キャンバス上）にドラッグ＆ドロップすることができます。キャンバス全体を再描画します。 速度低下は全くありません。
その例のリフレッシュレートは正常です。したがって、減速することはありません。