Canvasでクラウドソーシングのプロジェクトを作る - ページ 18

新しいコメント
 

残念ながら、画像更新の遅れに対処するために、「デジタルマスク」を用いて配列を保存する試みは、現在では成功していない。しかし、失敗作というわけでもありません。遅れの原因について決定的な結論を出し、世界的な解決策を見出すことができなかっただけです。

完成した画像をメモリに保存し、その領域で作業する一般的な方法を考えるにあたり、さまざまな選択肢を検討しました。良い解決策だと思っていたものが、よくよく考えてみると現実的でないことが判明した。

というわけで、--私の結論です。

1.画像を配列で保存する場合、配列はたくさんあるはずです。つまり、各リソースにはそれぞれ専用の定数メモリの配列が必要です。私の実装では、キャンバス（リソース、キャンバス）の数はウィンドウの数の数倍にもなり得ます。

その理由を説明します。

場合によっては、この方法は、すべてのウィンドウ・オブジェクトを1つのキャンバスに描くよりもはるかに便利です。例えば、「視野（VEIW BOX）」要素で表をスクロールする場合、この要素内の別のキャンバスに表の要素を配置し、このキャンバスを全体のオブジェクトとしてスクロールするのが便利です。そのため、このような要素には、それぞれ別のkanvasが搭載されています。そうでない場合は、メモリに保存されているウィンドウの画像全体を上書きする必要があります。これでは、間違いなくもっと時間がかかってしまいます。

さらに、1つのキャンバスにすべてのウィンドウを描くのはかなり不便ですが、ではどうやって移動させるのでしょうか？例えば、チャート領域全体をカバーする "メガ "キャンバスを1つ作成するとします。私たちのすべての窓は、その上に描かれることになります。カンヴァスに窓を描いた後、窓を移動させようとするが、そのためにはこの一枚の「メガ」カンヴァスの絵全体を書き直さなければならない。絵は非常に大きく、書き換えられる値の量も膨大になります。仮に画像が保存されたとしても、カーソル移動のたびにメモリ内の膨大な領域を上書きすることになる。これは明らかに非効率です。

2.画像を保存して作業する方法はないかと考え、「ResourceReadImage()」という関数を思い出したのです。説明： リソースを読み出し、その数値マスクを配列に格納する。つまり、 - 画像はすでに端末レベルで保存されており、この関数を使って呼び出すことができるため、保存する必要はないのです。これにより、作業が大幅に簡略化されます。そして、「ResourceReadImage()」で画像を取得し、それを配列に格納して、インターフェースの「イベント下にある」特定の要素に関連する配列の値を変更することができるのです。この方法は、より魅力的に見えると思います。しかし、「ResourceReadImage()」を使って配列に 画像を入れるのに、どれくらいの時間がかかるのだろうという疑問が残ります。もちろん、これはキャンバスの面積にも依存します。視覚的に全く目立たないかもしれませんが、いずれにせよ、カーソルが特定のカンヴァス領域上にあるときに一度だけ読み込まれるようにします。他のカンヴァスに移動するときは、配列をクリアして、他のカンヴァスの画像をアップロードすることができます。

とにかく、今は最終的な解決策を持っていないんです。ResourceReadImage()関数で試してみて、画像の読み込み時間を計測し、配列の中の画像の領域を扱うシステムを開発しなければなりません。

以上、今回はこの辺で。
 

Реter Konow:

私のインターフェイスの実装では、キャンバス（リソース、キャンバス）の数はウィンドウの数の数倍になることがあります。 これは、実務上必要なことです。

あなたの練習にはそれが必要です。

しかし、あなた自身の実践が示すように、この実装はスピードと利便性の点で欠陥があります。

実践してみるとわかりますが、1つのキャンバスで作業する方が便利ですし、キャンバス上に一時的にテーブルウィンドウを描いて、メインでBitBltを使っても 支障はありません。

なぜ、「配列がたくさんあるはずだ」と計画したのかがわかりません。「でも、それが行き止まりであることは、自分でもわかっているはずです。

 
o_O:

これが、あなたの練習に必要なことです。

しかし、あなた自身の実践が示すように、このような実装は、スピードや利便性の点で欠陥があります。

実践してみるとわかりますが、1つのキャンバスで作業する方が便利ですし、キャンバス上に一時的にテーブルウィンドウを描いて、メインでBitBltを使っても 支障はありません。

なぜ、「配列はいくつもあって、しかも無限にあるはずだ」と考えたのか、その理由がわかりません。「でも、それが行き止まりであることは、自分でもわかっているはずです。

もしかしたら、もっと良い解決策を見つけたのかもしれません。ぜひ見てみたいですね。できれば、クリックしたときのエレメントの反応の速さがはっきりわかるようなgifを投稿してください。この後、私のGIFを掲載します。私が何を言っているのか、あなたが何を言っているのかがわかるでしょう。
 
Реter Konow:
もしかしたら、もっと良い解決策を見つけたのかもしれません。ぜひ見てみたいですね。できれば、クリック時の項目の応答速度がはっきりわかるようなgifを投稿してください。この後、私のGIFを掲載します。私が何を言っているのか、あなたが何を言っているのかがわかるでしょう。

録画はしていませんが、一例を送ります。 簡単なスケッチです。

ドロップダウンリストは600個あります。

マウスを動かすと、イベントや色の変更ごとに、CCanvas全体が再描画されます。このインタラクティブ性を得ることができます。

ビットマップのプロパティで最終的なサイズを確認できます - 1500x600 px（あなたの800x500と250msの遅れと比較して）。これは90万画素に相当し、すべて瞬時に再描画されます。 秒単位は論外です。

各リストは、まずそれぞれのキャンバスに独自のサイズで描画され（オーバーフローしないように）、その後、全体的に掘り下げられていきます。つまり、マウスイベント1回あたり600回のResourceCreateを呼び出して いることになります。
つまり、反応速度でわかるように、アニメを見せるにはコマ数が十分なのです。

MTの開発者は、遅延のない満足のいくツールを提供してくれました（ResourceCreate bitmapsのことです）。

ファイル:
Gtest.ex5  150 kb
 
o_O:

録画はしていませんが、一例を送ります。

は600のドロップダウンリストがあります。

マウスを動かす - イベントと色の変更ごとに、CCanvas全体が再描画されます。

ビットマップのプロパティで最終的なサイズを確認できます - 1500x600 px（あなたの800x500と250msの遅れと比較して）。これは90万画素に相当し、すべて瞬時に再描画されます。 秒単位は論外です。

各リストは、まずそれぞれのキャンバスに独自のサイズで描画され（オーバーフローしないように）、その後、全体的に掘り下げられていきます。つまり、マウスイベント1回あたり600回のResourceCreateを呼び出して いることになります。
つまり、反応速度でわかるように、アニメを見せるにはコマ数が十分なのです。

MTの開発者は、遅延のない満足のいくツールを提供してくれました（ResourceCreate bitmapsのことです）。

まあ、その言葉を裏付けるには十分なのだが......。しかし、昨日の質問の繰り返しになりますが、画像は保存されているのでしょうか？

昨日も言いましたが、一度作成した画像を保存しておき、その中の特定の部分のみを変更して、すぐにResourceCreate()に送れば、遅延はありません。キャンバスを使った手法は、まだ馴染みがありませんね。どのようにしてこの結果を得たのか、まだわかりません。

もう一つ質問があります。CCanvasクラスを使って上記の例を作成しましたが、このソリューションの実装原理を説明してください。

おそらく、そこではビット演算を使って画像処理をしているのでしょう。まだ扱っていない。


P.S. しかし、私は自分で秘密を解くのが好きなのです...)とにかくこの問題を解決します。

 
Реter Konow:
CCanvas クラスを使用して上記の例を作成しましたが、このソリューションの実装原理を説明してください。

原則は直線的で、コントロールのリストを通って、それぞれをキャンバスの必要な位置に描画します。
コントロールの描画にはCCanvasの機能のみが使用されます。自分では何も描いてないんですよ。

例：折りたたまれたフォームのリストは2つの要素として描かれます - この例ではボタンです (これは他のスタイルでは異なります)
というキャンバス関数があります。
FillRectangle // 背景を塗りつぶす
長方形 // 周囲のフレーム
FontSet // フォントを設定する
TextOut // 出力テキスト

そこでビット演算を使って画像処理をしている可能性があります。

いいえ。

は画像が保存されていますか？

はい、CCanvas にある配列の中にあります。

一度作成した画像を保存し、その中の特定の領域だけを変更し、すぐにResourceCreate()に送れば、遅れは生じません。

というのは、ちょっと違う。

この例では、配列全体が再描画されます。再描画のたびに配列はクリアされ、キャンバス全体が再び塗りつぶされます。そして、ResourceCreateが呼び出さ れる。

 
o_O:

私の例では、配列全体が再描画されます。再描画のたびに配列はクリアされ、キャンバス全体が再び塗りつぶされます。そして、ResourceCreateが呼び出さ れる。

精緻な回答ありがとうございます。

不思議なことに、私も同じです。ウィンドウ全体の画像は、インターフェースイベントごとに完全に再作成されます。ローカルな一次元配列に構築され、この手続き完了後にResourceCreateに 送信される。

なんで遅くなるんだろう・・・。明日は、ウィンドウサイズとアイテムの応答速度の相関を示すGIFを掲載します。

これはとても不思議なことだ...。

 
Реter Konow:

詳しい返信ありがとうございました。

不思議なことに、私も同じです。ウィンドウ全体の画像は、インターフェースイベントごとに完全に再作成されます。ローカルな一次元配列に構築され、この手続き完了後にResourceCreateに 送信される。

なんで遅くなるんだろう・・・。明日は、ウィンドウサイズとアイテムの応答速度の依存関係を示すGIFを投稿します。

これはとても不思議なことだ...。

差し支えなければ、タスクマネージャでCPU負荷のgifアニメーションを作ってみてください。あるいは、sergeev さんのようにコンパイルしたファイルを投稿 する方が簡単です。だから、自分でテストすることができるのです。
 
Anatoli Kazharski:
難しくなければ、タスクマネージャでCPU負荷のgifアニメーションを作ってみてください。あるいは、sergeev さんのように、コンパイルしたファイルを投稿 する方が簡単です。だから、自分でテストすることができるのです。

よし、CPU負荷の動画を作ろう。しかし、コンパイルされたファイルについては、まだ掲載しません。

ただ、虫は非常に恥ずかしい...))

直したら、必ず掲載することを約束します。

 
Реter Konow:

よし、CPU負荷の動画を作ろう。しかし、コンパイルされたファイルについては、まだ掲載しません。

ただ、バグが非常に恥ずかしい...)))

修正したら、必ず投稿します。

オッケーです。ゆっくりでいいんです。)
1...111213141516171819202122232425...45
新しいコメント