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

新しいコメント
 
Andrey Barinov #:

また、フルスクリーンのキャンバスは変更するたびに完全に再描画されるが、50ミリ秒もかからない...。

最もコストがかかるのはテキストの描画だ。そのため、毎回TextOutを使わないように、配列に格納している。その方がずっと速くなる。

はい、 TextOutは使って います。 それで何ができるか考えてみる。

 
一般的には、次のリリースまでに描画ブロックをリファクタリングしてスピードを上げる。 しかし、最も重要なのはエンジンを完成させることだ。
 
Реter Konow #:

10～17個のウィンドウの面積の合計は、フルスクリーンよりはるかに大きい。同感だ。さらに、影、アイコン、フレームを作成するために必要な二次的な追加描画......。

そして、TextOutについては 、私がチェックして書くつもり だ。面白いアイデアだ。

私はあなたの単純な算術を理解していない :)。私の演算では、ユーザーに見えないピクセルを描画する必要はないし、描画するためのキャンバスの最大サイズはピクセル単位の表示サイズによって制限されている。

ウィンドウがいくつあっても、レイヤーで描画する。ウィンドウの数は100にもなる。単純なプリミティブは極わずかな時間で描画される。一番長いのは、上に書いたようにテキストだ。しかし、それらは最初の使用時にTextOutの助けを借りて、さらにすでに準備のできた配列から。

 

今後の作業計画を承認する必要がある。

毎週更新する。土曜日か日曜日

1.次のリリースでは、エンジンのフルバージョンをリリースする。バグを修正し、レンダリングをスピードアップする。

2.回目のリリースはテーブル専用になる。基本的な機能を復活させます。

3.3番目のリリースでは、動的なテーブルを作ります。 週間以内に実装したい。やってみます。

4.4番目のリリース - ダイナミックウィンドウ。 完成版を掲載するつもりだ。


現段階では、ビルダー、エンジン、マークアップ 言語の基本バージョンは完成したと考えてよい。

KIB-codeで書かれたテンプレートのブランチを 必ず開設し、完成したウィンドウやエレメントのグループを掲載するつもりだ。インターフェイスを作りたい人たちが簡単に作れるように、イラストも添えます。

そして、人々があらゆる可能性を使えるように、チュートリアルの記事を書いていこうと思います。


このスレッドでは、できる限りコード、写真、説明資料を投稿し続けるつもりだ。私は上記の作業でとても忙しくなるだろう。

 
パースはない。テキストやシャドウなどを駆使したインターフェイスは、弱いプロセッサで最大50msだ。
バグを探してください。
プロファイリングを実行してください。どの関数が95%の時間を食っているか見てください。
たぶん、ChartGetやXY関数を使っているのでしょう（チャートへのリンクはありませんが）。
とにかくプロファイリングを実行してください。たった40秒しかかからない。
 
KIBコードで書かれたテンプレートブランチ
ビルダーのコードと混ぜてはいけない。別のプロジェクトとしてリリースされるべきです。
 
Andrey Barinov #:

私はあなたの単純な算術を理解していません :)。私の計算では、ユーザーに見えないピクセルをレンダリングする必要はなく、レンダリングのためのキャンバスの最大サイズはピクセル単位のディスプレイサイズによって制限されます。

私はレイヤーで描画するので、ウィンドウがいくつあっても、すべて1つのビットマップになります。ウィンドウの数は100にもなる。単純なプリミティブはごくわずかな時間で描画される。一番長いのは、上に書いたようにテキストだ。しかし、それらは最初の使用時にTextOutの助けを借りて、さらにすでに準備のできた配列から。

つの大きなキャンバスで作業するには、多くの制限がある。このオプションについてはすでに考えていて、ニコライとも話し合った。

標準のCcanvasクラスを使うからそうなるのであって、その枠の中には既成のソリューションがある。しかし、私は Ccanvas クラスを使っていません。レンダリングコードはすべて個人開発です。だから私は、「すべてのものに1つのキャンバスを」というコンセプトにはこだわらない。私の意見では、グラフィカルな環境では技術的に不便で非効率的なソリューションだ。1つのビットマップを持ち、プログラムによってその上に画像の相互作用を構築するよりも、ビットマップオブジェクトのセットを使い、既製のリソースを添付する方が簡単だ。想像することさえ難しい。しかし、これは本題ではない。

キャンバスが1つしかない場合、マルチウィンドウGUIのコンセプトを実現するのがどれほど難しいか想像してみてほしい。私ならそんな仕事は引き受けない。

しかし、これでも決定的ではない。キャンバスが1つしかない場合、インターフェイスのウィンドウを移動させるにはMQL環境内で 再描画する必要があるからです。 一方、各ウィンドウが独自のビットマップオブジェクトを占有し、ObjectSetInteger()関数で移動させる場合、移動したオブジェクトの再描画はMQL環境外で動作する標準関数で 行います。そのため、はるかに高速です。

他のソリューションがより効果的に機能するよう、開発の方向性が異なるだけです。


TextOutに関する ヒントをありがとうございました。この点を調査してみます。

 
hini #:
テンプレート・ブランチはKIBコードで 記述さ れる。
ビルダーのコードと混ぜてはいけません。別のプロジェクトとしてリリースされるべきです。

はい、デバッグのために、ユーザー・プログラムをエンジンから切り離すことを実装するつもりです。おそらく誤解している。

 
Реter Konow #:

一枚の大きなキャンバスで仕事をするのは限界がある。私はすでにそのような選択肢を考え、ニコライとも話し合った。

標準のCcanvasクラスを使っているからそうなっているのであって、その枠組みの中には既成のソリューションがある。しかし、私は Ccanvas クラスを使っていません。レンダリングコードはすべて個人開発で書いている。だから、私は「すべてのものに1つのキャンバスを」というコンセプトにはこだわらない。私の意見では、グラフィカルな環境では技術的に不便で非効率的なソリューションだ。1つのビットマップを持ち、プログラムによってその上に画像の相互作用を構築するよりも、ビットマップオブジェクトのセットを使用し、既製のリソースを添付する方が簡単です。想像することさえ難しい。しかし、これは重要なことではない。

キャンバスが1つしかない場合、マルチウィンドウGUIのコンセプトを実現するのがどれほど難しいか想像してみてほしい。私ならそんな仕事は引き受けない。

しかし、これでも決定的ではない。キャンバスが1つしかない場合、インターフェイスのウィンドウを移動させるにはMQL環境内で 再描画する必要があるからだ。 一方、各ウィンドウが独自のビットマップオブジェクトを占有し、ObjectSetInteger()で移動する場合、移動時の再描画はMQL環境外で動作する標準関数に委ねられる。したがって、はるかに高速になります。

他のソリューションがより効率的に動作するように、開発の方向性が少し異なるだけです。


TextOutについての ヒントをどうもありがとう。この点について調査してみます。

ただ、標準のカンヴァスは使っていません:)。

それに、1つのビットマップにマルチウィンドウ・インターフェイスを実装する方が簡単だと思ったんだ。しかし、それは人それぞれだ！


実際、ObjectSetIntegerなどを使うよりも、キャンバス全体を再描画したほうが速いようだし。

 
Andrey Barinov #:

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

それに、1つのビットマップにマルチウィンドウのインターフェイスを実装する方が簡単だと思ったんだ。しかし、人それぞれだ！

残念なことに、すべての場合ではありません。私のタスクでは、限られたビットマップのセットで作業する方が技術的に簡単だ。そして100％速い。はるかに 速い。

でも、他の開発では他のソリューションの方がうまくいく。:)

1...484950515253545556575859606162...69
新しいコメント