記事"可視化の可能性 Rのプロットに似たMQL5のグラフィックス ライブラリ"についてのディスカッション - ページ 5

新しいコメント
 
Artyom Trishkin #:

すべてのスムージング方法は、線の不透明度に大きく依存します。不透明度が50%程度になると、すべてがアンエイリアスになり、アーティファクトが発生します。

現在では、完全に不透明な線でもアーティファクトがあります。

私たちは、滑らかさを失うことなく、（Wuのアルゴリズムを使って）滑らかなエッジで完全に不透明な円を描こうと話していました。

これには、平滑化されたエッジで塗りつぶす特別な方法が必要です。

 
Anatoli Kazharski #:

完全に不透明なラインでもアーティファクトが発生するようになった。

それは、（Wuのアルゴリズムを使って）滑らかなエッジを持つ完全に不透明な円を、滑らかさを失うことなく描こうとすることでした。

これには、平滑化されたエッジで塗りつぶす特別な方法が必要です。

自分ではできないということですね？

 
Artyom Trishkin #:

自分一人では無理なんですか？

どうしてですか？やってみたら？)

ご指摘のケースも解決できます：

取引、自動取引システム、取引戦略のテストに関するフォーラム

ビジュアライズする！RのplotのアナログとしてのMQL5のグラフィカルライブラリ" についての議論

Artyom Trishkin, 2023.07.31 12:39 AM

すべてのスムージング方法は、線の不透明度に強く依存します。不透明度が約50%になると、すべてが滑らかでなくなり、アーティファクトが発生します。

つまり、完全に透明なキャンバス(CCanvas)に描画する場合は、下のレイヤー(チャートと他のオブジェクト)を考慮して描画することができ、アーティファクトは発生しません。

しかし、これはかなり不便で面倒なようだ。また、パフォーマンスにどの程度影響するかも不明だ。やはりターミナルの開発者にはこのバグを直してもらいたい。

 
Anatoli Kazharski #:

なぜダメなのか？試してみてください！)

あなたが言った事件も解決できますよ：

つまり、完全に透明なキャンバス（CCanvas）へのレンダリングは、下のレイヤー（チャートおよびその他のオブジェクト）を考慮して行うことができ、アーティファクトが発生しません。

しかし、それはかなり不便で面倒なようです。パフォーマンスにどの程度影響するかも不明だ。やはりターミナルの開発者にはこのバグを直してもらいたい。

もし開発者ではなくフォーラムのメンバーであれば、ニコライ・セムコ（@Nikolai Semko）にそのようなタスクを送り、解決してもらおうと思っている ;)

 
Artyom Trishkin #:

このようなタスク（開発者ではなく、フォーラムのメンバー）は、ニコライ・セムコ（ Nikolai@Nikolai Semko）に送って解決してもらおうと思っている。

彼は1つのキャンバスのみで作業している。

そして、すべてを1つのキャンバス上で動作させるためにグラフィック・ライブラリを書き直す準備はできていない。

興味深いことではあるが、どれだけの時間がかかるかを考えると、今のところそのような挑戦をする決心がつかない。今は昔ほど時間がないんだ。

 
Anatoli Kazharski #:

1つのキャンバスにしか使えない。

それに、すべてを1つのキャンバスで動作させるためにグラフィック・ライブラリを書き直す気にはなれない。

面白いけど、どれだけの時間がかかるかを考えると、今のところそのような挑戦はできない。今は昔ほど時間がないんだ。

まあ、アルゴリズムだからね。キャンバスが1枚だろうが、何枚だろうが違いはない。

 
Artyom Trishkin #:

まあ、アルゴリズムだからね。それが1つのキャンバスに描かれているか、複数のキャンバスに描かれているかで何が変わるんだ？

これまで2つの問題を議論してきた：

1.1.私が元々話していたのがこれだとすれば、アルゴリズムによる解決で十分なケースもあるだろう。

2.2.もしあなたがおっしゃるような問題であれば、2、3の関数では解決できません。すべてのレイヤーが配列に格納されるスキームが必要です。各レイヤーは、その下のレイヤーに何が描かれているかを考慮して描画されなければならない。さらに、CCanvasクラスのすべてのメソッドを修正する必要がある。各ピクセルの色は、透明度を考慮して下のピクセルとブレンドされるべきである。そうすれば、アーティファクト（隙間、ギザギザなど）は発生しない。うまくやれば、ぼかしで半透明を実装できる。これらはすべて、1つのキャンバスで実装するのは簡単です。しかし、複数のキャンバスを使用する場合は、実装がはるかに難しくなります。

 
Anatoli Kazharski #:

1つのキャンバスにしか使えない。

それに、すべてを1つのキャンバスで動作させるためにグラフィック・ライブラリを書き直す気にはなれない。

興味はあるけれど、どれだけの時間がかかるかを考えると、今のところそのような挑戦はできない。今は昔ほど時間がない。

実際、私は複数のキャンバスを使用している（通常は4枚以下）。
常に黄金律がある。つのキャンバスにスタティックとダイナミクスをすべて描くという極端もあれば、すべてのオブジェクトを別々のキャンバスとして描くという極端もある。
忘れてはならないのは、透明度のある2つのキャンバスが重なっている場合、CPUは（Win10-11ではGPUかもしれませんが、やはりCPUだと思います）各ピクセルを均質な（透明度がゼロでない）背景と混合してしまうということです。
ここで、パフォーマンスを向上させるためにキャンバスまたはその一部をキャッシュする習慣をJSから借りることができる。
アンチエイリアス処理された円に関しては、半径が～5ピクセル未満の円に対して（パフォーマンスの点で）理想的な、そのような円の変形をすでに発表している。その関数はiDot()と呼ばれ、3DStarsのコードの中にあったと思います。これは非常に原始的で短い（約10行のコード）。より大きな半径の円では、パフォーマンスの点で最適とは言い難い。より大きな半径の場合、高性能な関数はすでに100行を超えるコードになっている。
そう、キャンバス上で何年も脳の新しい神経接続を確立してきた私は、今ではどんなレベルでもキャンバス上でライブラリを作ることができる。時間とやる気はあるだろう。
呉のアルゴリズムは時代遅れとされている。
 
Anatoli Kazharski #:

私たちは2つの課題について話し合った：

1.元々私が話していたものであれば、場合によってはアルゴリズムによる解決で十分でしょう。

2.もしあなたがおっしゃるようなものであれば、2、3の関数では不十分です。すべてのレイヤーが配列に格納されるスキームが必要です。各レイヤーは、その下のレイヤーに何が描かれているかを考慮して描画されなければならない。さらに、CCanvas クラスのすべてのメソッドを修正する必要がある。各ピクセルの色は、透明度を考慮して下のピクセルとブレンドされるべきである。そうすれば、アーティファクト（隙間、ギザギザなど）は発生しない。うまくやれば、ぼかしで半透明を実装できる。これらはすべて、1つのキャンバスで実装するのは簡単です。しかし、複数のキャンバスを使用する場合は、実装がはるかに難しくなります。

私はスムージングのアルゴリズムについてだけ話しているつもりだった。透明なキャンバス同士を重ねることについては関係ない。とはいえ...。重ね合わせれば必ず新たな問題が出てくる。だからニコライのことを言ったんだ。彼は長い間、すべての神経接続を持っていて、おそらく彼の脳はすでにキャンバスに起こりうるすべての問題を考慮して自分で考えているんだ）。

 
Artyom Trishkin #:

私はスムージングのアルゴリズムについて話しているだけだと思った。透明なキャンバスを重ねることについては言及していない。しかし...重ね合わせれば、必ず新しい問題が出てくる。だから、ニコライのことを言ったんだ。彼は長い間、すべての神経接続を持っていて、おそらく彼の脳は、キャンバスに起こりうるすべての問題を考慮して、すでに自分で考えているんだろう）。

アーテム、これらは本当に新しい神経接続を必要とする些細な作業ではない。例えば、SVGにはviewBoxという概念がある。私はすでにそれがどのように機能するかについて多くのビデオを見て、多くのドキュメントを読んで、多くのコードを書きましたが、それでも時々つまずきます。何度かすべてを理解したように思えたのに、必要な神経接続がまだできていないのだ。

1234567
新しいコメント