リモートデスクトップエンジニアのブログ。

えー、コメントにてBrynhildrよりVritraの方が速いとゆー御報告を受けまして調べましたところ、

た、確かに・・・。

しかも、Brynhildrの転送サイズがドえらいデカイです。

ちなみに上の環境は、Windows7で自分自身に接続でDWMをOffにしてMaxFPSをMaximumでWindowScrollをOnでHybridCompessをOffでEncryptionをOffとかにしてウインドウサイズを最小にしたらこうなりました。実質の画像転送サイズは116x32みたいです。デスクトップのCorei5（SandyBridge）でこんな数値ですので最新の上位のCPUだともっと出ると思います。すごい数値が出てる方は是非教えて頂きたいです。なんかベンチマークみたいで楽しいです。

自分はこれを頂上決戦モードと呼んでいます。

なんでBrynhildrの方が遅いのかを調べていましたところ、今回実装した遅延防止機能が影響している模様です。通常ですとそれほど差が無いのですが、上のようにFPSが4000越え位ですとかなり顕著に出てしまっています。差が700位もありますので。

これは、映像系の通信は片方向ですので、双方向である操作系の通信で遅延の検出を行っていたのですが、MaxFPSをMaximumにすると操作系の通信が1秒間に約20万回とあまりにも増えてしまい、遅延が発生していると勘違いするような不安定な状態になってしまい、映像系の処理速度を緩めてしまっているのが原因でした。

ちなみに、なぜ今回から遅延防止処理が入っているかと言いますと「Orthros 1.6.2」が関係しています。Orhrosはこれまで映像系の通信が遅延防止の為に双方向だったのですが、「1.6.2」より速度を出す為に片方向にシフトした事が要因で御座います。片方向で速度が1.2~1.5倍になった分、どこかで遅延防止機能を追加する必要があったのです。

あと、転送サイズが大きくなっているのは、今回のバージョンアップで行った操作系の通信の速度を上げた為に発生しております。ほんの256バイト程度の双方向の通信なのですが、これが1秒間に約20万回も発生している為にその転送サイズが上乗せされております。ちなみに前回までは秒間30回程度でした。ここまでの回数は想定外と言わざるを得ないですが、逆にここまですごい通信処理ができるのかと思ってしまって自分でもビックリです。完全に自分のポカと言わざるを得ませんが。ちょっと操作系の通信をMaxFPSの影響を受けるのはちょっと次で保留で・・・。

尚、ソースをちょいちょいっと修正したら下のようになりました。



もし、MaxFPSをMaximumなどの上のような状態で御利用の方がいらっしゃいましたら、恐れ入りますけど次のバージョンまで御待ち頂ければと思います、恐れ入ります。

なんか毎度毎度ですいやせん。