MQLで書かれたUIのギャラリー - ページ 57 1...505152535455565758596061626364...83 新しいコメント Реter Konow 2024.07.29 20:08 #561 Реter Konow #:ニコライ・ セムコ ...そして、50msのフルスクリーンは、私のためにも動作 します。 テストは概算です。ほぼ同じ大きさの3つのキャンバス(アイコンウィンドウ)でウィンドウを開く速度を測定したところ、~70ミリ秒でした。すべてのキャンバスの面積を合計すると(要素なし)、ちょうどノートパソコンの画面17インチ分の面積になる。これには、キャンバスの上に描かれたエレメントやアイコン自体のベース部分の面積は含まれていません。つまり、想定されるフルスクリーンの領域を色で埋めるには、~50ミリ秒ということになる。正確にはまだ測っていない。象」が部屋の真ん中にいるのに、なぜ?:) Nikolai Semko 2024.07.29 21:36 #562 私は50msについて、過負荷で最適化されていないインターフェースだと話していた。3-10msは普通だ。しかし、プロファイリングをしてみてほしい。あなたのコードに多くの発見があるはずだ。 Реter Konow 2024.07.29 21:44 #563 Nikolai Semko #: 私は50msについて、過負荷で最適化されていないインターフェースだと話していた。3-10msは普通だ。プロファイリングをしてみてほしい。あなたのコードに多くの発見があるはずだ。 ニコライ、これは単なる数字だ。具体的な情報が必要だ。少なくとも画面サイズ。そうすれば正確な計算ができる。 Реter Konow 2024.07.29 21:48 #564 キャンバスへの描画は配列の初期化である。最大速度を知るのは簡単で、配列を埋めるループを持つ関数がそれを明らかにしてくれる。配列のサイズは、条件画面のピクセルの合計に対応させる。 Nikolai Semko 2024.07.29 21:52 #565 ジャガイモ畑に行きたがらなかったスターリッツみたいだな。プロファイリングをして... Реter Konow 2024.07.29 22:02 #566 Nikolai Semko #: ジャガイモ畑に行きたがらなかったスターリッツみたいだな。プロファイリングをして... やったよ。GIFを送るよ。 Реter Konow 2024.07.29 22:24 #567 製図ブロック内のサイクルを詳細に調査する必要がある。表面的なプロファイリングでは全体像はつかめない。しかし、何がポイントなのかはすでに明らかだ。私はここに書いた#553.私は間違っていないと思う。(図面ブロックのドラフト版。) Реter Konow 2024.07.30 11:41 #568 Реter Konow #:...コードを変更して、レンダリングを2、3倍速くする方法があるんだ。 でも、メインの仕事が終わってからにするよ. タスクの複雑さと最終結果の価値を分析した。 結論:やる意味がない。 複雑なグラフィックとスクロールバーを持つ15個のウィンドウを作るのに1秒半かかるのは普通の結果である。最初の描画は、ウィンドウを開く前に行うことで、ユーザーの目から隠すことができる。視覚的には、ウィンドウは0.5秒の休止の後、即座に表示される。もちろん、15個のウィンドウを一度に開きたいのであれば、ありえないことだが。 窓の裏側を描く必要はない。20msのゲインだ。それは印象的ではありません。 先週、主なことが達成された。最初のビルドを除くすべてのイベントで保存された画像を使用することだ。 これは インターフェイスのスピードにおいて大きな進歩 だ。 残りの遅延は、フォーカスを変更したときのウィンドウの再描画や、不必要な呼び出しに関係している。簡単に修正できる。この大きな利点を、それほど重要ではないロード時間のせいで無視してほしくない。しかし、私は自分自身の関心の焦点を移した。そうすべきだ。 ここで、最初のレンダリングの速度の問題は、現在の開発とは無関係であり、無関係であるため、私はその問題を閉じた。 次回の更新は日曜日。私は、ソフトウェアとユーザー・プログラムとの相互作用のメカニズムが概念的に完成したエンジンを発表する予定だ。 hini 2024.07.30 14:44 #569 Реter Konow #: 私は仕事の複雑さと最終的な結果の価値を分析した。 結論は、意味がないということだった。 秒半で複雑なグラフィックとスクロールバーを持つウィンドウを15個作るのは普通の結果だ。ウィンドウを開く前に最初のグラフィックを描き、ユーザーに見えないようにすることは可能である。視覚的には、ウィンドウは半秒間の休止の後すぐに表示される。もちろん、ユーザーが15個のウィンドウを同時に開きたいのであれば、このようなことはありえない。 ウィンドウの背面を描く必要はない。20ミリ秒のゲインがあります。それは驚くべきことではありません。 先週、私たちは最初のビルドを除くすべてのイベントで保存された画像を使うという主な目標を達成した。 これは インターフェイスにとって大きなスピードアップ だ。 残りの遅延は、フォーカスを変更したときのウィンドウの再描画や不要な呼び出しに関連していた。これは簡単に修正できる。ロード時間がそれほど重要でないからといって、この大きな改善を無視したくはない。しかし、私はフォーカスを移した。あなたは ここで、最初のレンダリング速度の問題は、現在の開発には関係ないし重要でもないので、終わりにした。 次の更新は日曜日です。ソフトウェアとユーザープログラム間の相互作用のメカニズムが概念的に完成したエンジンを紹介する予定だ。 そう、まずは完全に機能するソフトウェアを世に送り出すことが最も重要なのだ。 Реter Konow 2024.07.30 14:55 #570 hini #:そう、まずはフルプログラムをリリースすることが重要だ。 そうしよう。 1...505152535455565758596061626364...83 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ニコライ・ セムコ
...そして、50msのフルスクリーンは、私のためにも動作 します。
テストは概算です。ほぼ同じ大きさの3つのキャンバス(アイコンウィンドウ)でウィンドウを開く速度を測定したところ、~70ミリ秒でした。すべてのキャンバスの面積を合計すると(要素なし)、ちょうどノートパソコンの画面17インチ分の面積になる。これには、キャンバスの上に描かれたエレメントやアイコン自体のベース部分の面積は含まれていません。つまり、想定されるフルスクリーンの領域を色で埋めるには、~50ミリ秒ということになる。正確にはまだ測っていない。象」が部屋の真ん中にいるのに、なぜ?:)
私は50msについて、過負荷で最適化されていないインターフェースだと話していた。3-10msは普通だ。
ジャガイモ畑に行きたがらなかったスターリッツみたいだな。
製図ブロック内のサイクルを詳細に調査する必要がある。表面的なプロファイリングでは全体像はつかめない。しかし、何がポイントなのかはすでに明らかだ。私はここに書いた#553
.私は間違っていないと思う。
(図面ブロックのドラフト版。)...
コードを変更して、レンダリングを2、3倍速くする方法があるんだ。 でも、メインの仕事が終わってからにするよ.
私は仕事の複雑さと最終的な結果の価値を分析した。
そう、まずは完全に機能するソフトウェアを世に送り出すことが最も重要なのだ。
そう、まずはフルプログラムをリリースすることが重要だ。