SSE4 — новый набор команд микроархитектуры Intel Core, впервые реализованный в процессорах серии Penryn (не следует путать с SSE4A от AMD)[1]. Он был анонсирован 27 сентября 2006 года, однако детальное описание стало доступно только весной 2007 года. Более подробное описание новых возможностей процессоров для программистов можно найти на сайте...
ブロックの始まりはこんな感じです。
私が理解する限り、あなたは独自のインタプリタ言語を作成したのですね。
こんな感じ？
またまた愚問です。
は、異なる要素を持つ各生成ウィンドウが1つのリソースなのか、それとも多くのリソースなのか？
しかし、より良い例えをするならば、HTMLでしょう。
先ほども言ったように、子にはグラフィカルなコンストラクタが必要です。アンドレイ・バリノフの ようなもの。
また、ビデオクリップが 長すぎる。45分から5分、あるいは3分に短縮する必要があります。
自分で答えを見つけようとしたことがありますか？
ヒント：google検索で、「DBL_MANT_DIG 53 52」と入力します。
ええ、ありがとうございます。見つけた。
1.私が理解する限り、あなたは独自のインタプリタ言語を作成したのですね。
こんな感じ？
そして、愚問です。
は、異なる要素を持つ各生成ウィンドウが1つのリソースなのか、それとも多くのリソースなのか？
とはいえ、HTML言語に例えた方がいいかもしれませんね。
先ほども言ったように、あなたの発案にはグラフィカルなコンストラクタが必要なのです。アンドレイ・バリノフの ようなもの。
また、ビデオクリップが 長すぎる。45分からは5分、あるいは3分に短縮するのが望ましい。
1.そう、「インタプリタ」の定義が、私が作ったものに一番合っていることがわかったのです（作っている最中は、それが何なのかさっぱりわからなかったのですが）。
2.形成された各ウィンドウは、複数のカンヴァス（資源）から構成される。最初の2つは、ウィンドウズ・プラットフォームです。以前は別の描画方法を使っていたため、半透明でグラフが透けて見える部分がありました。それを避けるために、背景にもう一つカンヴァスを追加しています。そうすると、技術は向上しているのに、キャンバスは背景のまま。技術に成長し、今さらながら捨てがたいですね。しかし、いずれはそれを取り除き、ウィンドウ・プラットフォームは1枚のキャンバスで構成されることになります。
また、"フィールド"(切り替え可能な画像タブ）が独立したキャンバスになっています。既成の画像が含まれているため、切り替えが早いのが特徴です。1枚のキャンバスにすべてを描くとなると、どうしても画像の切り替えが遅くなってしまうんです。とにかく、考えた末に、これがベストな選択だという結論に達しました。
3.ビジュアルグラフィックデザイナーは、昔も今も私の目標です。その実装が始まるまであと少し。その構造への理解がある。その実現に必要なコンセプトはすべて揃っています。作り方は知っている。必要なのは時間だけだ。
ZS. 私の開発の特長は、自発性 です。私は、インタープリターにもHTML言語にもなじみがなく、その仕組みがわかりませんでした。しかし、だからといって、似たようなものを作ったりするのはやめられません。うまくいけば、ずっと続けていけると思うんです。:)
一見すると、非常に無駄なメモリの使い方をしているように見えますが、実際はどうなのでしょうか？間違っているかもしれませんが。
理想的には、価格チャートを透過的に表示するキャンバスを1つだけ持つタスクが必要です。
MQL5の性能は、コーディングが正しければ、メモリにレディブロックを持たずとも、オンザフライでインターフェイス全体を形成するのに十分なものであるはずです。
面倒なインターフェースの性能アップのために、メモリリソースを犠牲にする可能性も否定できませんが。
これまでのアプローチで、ひとつ大きなアドバンテージがあると思います。
MQLコードそのものではなく、マークアップコードを生成する方が、本格的なグラフィカルコンストラクタを 作成しやすいと思われます。
しかし、それは象牙のような作業です。一見すると、非常に無駄なメモリの使い方をしているように見えますが、実際はどうなのでしょうか？間違っているかもしれませんが。
理想的には、価格チャートを透過的に表示するキャンバスを1つだけ持つタスクが必要です。
MQL5の性能は、メモリにレディブロックを持たずに、オンザフライでインターフェイス全体を形成するのに十分なものであるべきです。
面倒なインターフェースの性能を上げるために、メモリリソースを犠牲にする可能性も否定はしませんが。
これまでのアプローチで、ひとつ大きなアドバンテージがあると思います。
MQLコードそのものではなく、マークアップコードを生成する方が簡単なので、本格的なグラフィカルコンストラクタを 作成することができるでしょう。
しかし、それは象牙のような作業です。比較的小さなメモリオーバーランが残っています。その通りです。テキストやアイコンのような要素オブジェクトは、カーネル内で235ものプロパティを "不当に "与えられ、一方で自身のプロパティは数倍も少なくなっているのです。メインとなる要素オブジェクト、すなわちベースは235個のプロパティをすべて持つべきですが、アイコンとテキストオブジェクトはプロパティが少なくなっています。これにより、メモリオーバーが発生します。
メインアイテムのオブジェクトの行にもう60セル追加すれば、そこにテキストやアイコンのプロパティを入れられるというものです。そうすると、コアが "広く "なりますが、3分の2のオブジェクトを削除することができます。
メモリの節約になり、カーネルの構築速度も向上します。しかし、これを実現するのは技術的に困難です。多くの手直しが必要です。今のところ、メモリ消費量やビルドタイムはかなり許容範囲内です。しかし、完成度に限界はない...。
1枚のキャンバスを使うのはNGです。ウィンドウごとに1つのキャンバスを使い、フィールドごとに1つのキャンバスを使う方がはるかに簡単です。一般的なキャンバスは、もっと頻繁に描き直す必要があります。画像切り替えやウィンドウ移動のたびにスクロールについて...再描画が必ずしも高速でないことを考慮する必要があります。それはアルゴリズムではなく、グラフィックの「洗練度」にあるのです。説明しよう。
単純な長方形のラベル（例えば正方形）を描く場合、正しいセルが正しい値（色）で初期化されたピクセルの配列上を1サイクルすることになる。
フレームで正方形を描くと、ピクセルの配列上で2サイクルです。
四角に枠とアイコンを描けば、3サイクルです。
表面グラデーションのあるフレームと影のあるアイコンで正方形を描くと、ピクセル配列で4サイクル以上となります。
つまり、グラフィックが急峻であればあるほど、この画素の配列を周期的に「アイロンがけ」して、正しい画像を作る必要があるのです。そのため、再描画の必要性は低いほうがいい。
1つのキャンバスにすべての画像を表示すると、連続的に再描画することになります。したがって、良い解決策とは言えません。
ZS. 確かに課題は象牙のようですが、私ならできます。(助けは借りるが))。
ZS. ビデオありがとうございます！感動しました。:)
マウスでウィンドウサイズを変更していますか？
その場合、赤い四角が 表示されますか？
マウスでウィンドウサイズを変更していますか？
その場合、赤い四角が 表示されますか？
どこのスクエニの話か理解できない。
ダイナミックウィンドウは、マウスでサイズを変更することができます。それ以外にはないでしょう？
ZS：ダイナミックウィンドウは、初期状態では全画面サイズになっています。さらに、必要なサイズに「トリミング」されます。つまり、すでに作成されたビットマップの最大サイズに、そのダイナミズムのすべてが実現されているのです。
丸めの話題の続きです。
SSE4.1拡張命令セットをサポートする最近のIntelプロセッサは、丸めコマンドROUND{PS, PD}を持って いることがわかりました。AMDにも似たようなものがあると思います。
https://ru.wikipedia.org/wiki/SSE4#SSE4a
http://o-ili-v.ru/wiki/SSE4
MQL5コンパイラは、CPUレベルでこのコマンドを使用しないということでしょうか？私のIntel Kaby Lakeプロセッサはこのセットに対応しているので。
さらに、ベクトルのスカラー倍算まであるんですよ。