キャンバスがカッコいい! - ページ 66

[Yury Kulikov]

インターフェースの拡大縮小など、一部の作業については、画像リサイズ機能を大幅に簡略化することが可能です。

リソースを指定されたサイズに読み込む機能の一例。

bool  ImageFromResource(const string _resource,const int _w,const int _h,uint &_pic[])
{
   uint lp[];
   int wr, hr;
   if(_w<2 || _h<2) return(false);
   if(!ResourceReadImage(_resource,lp,wr,hr))
   {
      Print("Еrror loading resource: ",_resource);
      return(false);
   }
   if(_w!=wr || _h!=hr)
   {
      //resize image
      ArrayResize(_pic,_w*_h);
      double sw=(double)_w/wr;
      double sh=(double)_h/hr;
      //
      for(int _y=0; _y<_h; _y++)
         for(int _x=0; _x<_w; _x++)
            _pic[_y*_w+_x]=lp[int(_y/sh)*wr+int(_x/sw)];
   }else ArrayCopy(_pic,lp);
   return(true);
}

リサイズアルゴリズムの視覚的な比較。

[Fast235]

fxsaber:

このような端末の最小化により、大きなCPU負荷はほぼゼロになる。なぜこのような無駄なGUIが必要なのかが不明です。

これはプログラマーに感謝すべきことです。

例えば、最もポピュラーなビデオコーデックであるmadvrは一時停止しており、まるで採掘しているかのように食べます)

[Renat Fatkhullin]

fxsaber:

そうですね。高頻度のMarket Watchでは1台あたり数百文字になるようなTerminalを5台並列で動かすことは、開発者としてはあり得ないと思います。

このようなTerminalの最小化によって、大きなCPU負荷がほとんどゼロになると、とてもバカバカしくなります。なぜこのような非合理的にCPUを消費するGUIが必要なのかは不明である。

そして、1秒間に300回のGUIのレンダリングが無料だと思っているのか？

描き方が間違っている、描き終えていない、描き飛ばしている、と最初に主張することになる。

デスクトップの話なら、普通に速いビデオカードが必要です。高いレンダリングレートを噛み砕くことができます。ウィンドウを最小化することで、頻繁に描画するほとんどのアプリケーションの負荷を軽減することができます。

ちなみに、MetaTraderは1秒間に大量の相場が流れるため、100～300FPSを実現することができます。通常の番組のように1秒間に1〜2フレームではなく、引用ストリームによっては実際には1秒間に数百フレームを表示します。

[Fast235]

Renat Fatkhullin:

1秒間に300回guiを描くことが無料だと思っているのか？

描き方が間違っている、描き終えていない、描き方をサボっている、と最初に主張することになるのです。

デスクトップの話なら、普通に速いビデオカードが必要です。高いレンダリングレートを噛み砕くことができます。ウィンドウを最小化することで、頻繁に描画するほとんどのアプリケーションの負荷を軽減することができます。

ちなみに、MetaTraderは1秒間に大量の相場が流れるため、100～300FPSを実現することができます。通常の番組のように1秒間に1〜2フレームではなく、実は見積もりフローによっては1秒間に数百フレームもあるのです。

Renatさんは、今、私たちがここで実行しているコアあたり10 Intel procesとzen2高速のレベルであるすべての新しいプロセッサをテストしましたね？

私の知る限り、Intelはマルチスレッドが苦手ですが、Amdはマルチスレッドをうまく並列化しています。

[prostotrader]

キャンバス - クール!

トレードにどう役立つのか？

[Fast235]

Renatさん、ついでにお返事もお願いします。

[Nikolai Semko]

prostotrader:

キャンバス - クール!

トレードに役立つのか？

はい

[Nikolai Semko]

Yury Kulikov:

インターフェースの拡大縮小など、一部の作業については、画像リサイズ機能を大幅に簡略化することが可能です。

リソースを指定されたサイズに読み込む機能の一例。

リサイズアルゴリズムの視覚的な比較。

そうですね......ユーリ、私もそう思います。このような超高速アルゴリズムには生存権がある。
しかし、当然ながら、重大な品質低下を伴う。特に画像では、色の移り変わりが鮮明です。
例えば、このことを明確に示すスクリプトがあります。右側がこの高速アルゴリズム、左側が私のアルゴリズム（約4〜10倍遅い）です。
通常のスクリーンショットの縮小例。

ところで、なぜそのような点滅があるのか、その理由がわかりました。フレームごとにビットマップをリサイズしていたのがバカで、それが原因でした。今はそれを取り除いて、すべてがスムーズに動いています。

[Renat Fatkhullin]

Fast235:

Renatさんは、私たちがここで動かしている1コアあたり10個のIntel procesとzen2が速くなったレベルの新しいプロセッサをすべてテストされましたよね？

私の知る限り、Intelはマルチスレッドが苦手ですが、AMDはマルチスレッドをうまく並列化するので、良い解決策になります

最近のプロセッサーはどれも十分に高速に動作します。

特に、端末作業用のメモリやNVMeドライブが潤沢にあれば、なおさらです。ミドルレンジグラフィックカードを強く推奨します。

私たちの会社では、インテルは拒否して、1年以上前からサーバーとワークステーション用にAMD Epycだけを買っています。

[Fast235]

Renat Fatkhullin:

最近のプロセッサーはどれもかなり高速です。特に、メモリとNVMeディスクが潤沢にあればなおさらです。

ターミナルでは、ミドルレンジのグラフィックカードを強く推奨します。

当社では、インテルは拒否し、1年以上前からサーバーとワークステーションはAMD Epycのみを購入しています。

大いなる）