今は、Ubuntu版Mirror-DTCの開発フェーズで、サーバーの変更が終わったので、クライアントの変更に移っているのだが、処理性能が他OS用よりも少し悪い感じだったので、原因を調べて対策した。次バージョンでは性能も改善される。今日の時点で、クライアントについても、レジスト関連機能とサーバーからの接続機能には対応できたので、後は、録画機能と音声設定機能になるのだが、作者的には、デバッグ中に少し変な感じがした訳だ。その一つ目は、マウスは滑らかに移動している筈なのに、そのカーソルの移動がちょくちょく停止してしまう、というモノだった。原因を調べてみたのだが、マウスの移動イベント中にカーソル移動を表示に反映させるために行っているウインドウの再描画処理の頻度を制限してやれば、問題が無くなった訳だ。Android版では、OpenGL描画を行っているので、特別なウインドウは作らず、OpenGLでサーバー画像と合成する格好にしている。マウスカーソルを描画するにあたっては、カーソル位置指定を変更してOpenGLの描画を1回行えば良いだけなので、処理負荷的には問題は無い筈なのだが、上記の様に、この処理の頻度を落としてやれば、問題は無くなった訳だ。言う事で不思議だったのだが、UbuntuではUI系の処理は全てメインスレッドで行わなければならない事になっていて、OpenGL描画も同様なので、マウス移動中なんかは、そのイベント処理のためにメインスレッドが消費される分、画面描画が後回しにされ、結果的に、古い描画は行われないために、マウスカーソルが飛んでしまう様な現象になっているのかもしれない。上記は普通に使っていて不快に感じる現象なので、作者的には、現行版のリリース時に、この問題に気がつかなかった筈はない訳だ。調べてみたのだが、同じ現象は現行版でも発生した。2016モデルのParallelsで動作させているUbuntu16.04LTSでは問題は発生しないし、現在の開発環境であるUbuntu18.04LTSでも、デスクトップ環境をUnityとしてログインし直せば、問題は発生しなくなった。言う事で、上記の問題は、Mirror-DTCがサポート対象としているLTS版では、18.04LTSで始めて採用されたGNOMEデスクトップ環境絡みの問題になる様なのだが、上記の様に、マウスカーソルの描画頻度を制限して30FPS程度にしてやれば問題は無くなったので、次バージョンではそういう変更を加える事にする。二つ目の問題は、サーバーを操作していると、macOSやWindowsでクライアントを使っている場合と比べて、何となく、モッサリした感じがした事だ。具体的には、ウインドウをドラッグして移動したりすると、クライアントの画面描画では、そのウインドが少し遅れて追随する格好になっていたのだが、Ubuntu版クライアントの処理コードの多くは、少なくとも、macOS版とは殆ど同じになっている訳だ。PCでも、モッサリした感じになっていた訳だ。原因を調べてみたのだが、前述の様に、Ubuntuでは、描画関係はメインスレッドで行わなければならないので、データを受信してデコード処理等を行う別スレッドは、デコードが終わるとメインスレッドに描画内容を渡して、描画が終わるのを待っていたのだが、そこが問題だった訳だ。前述の問題と同様に、メインスレッドの処理が遅い分、描画の終了を待っていると総合的な処理性能が低下するので、Ubuntu版については、他OS版よりもモッサリしてしまっていた訳だ。普通は、無駄な処理が増えるので、総合性能が低下するのだが、Ubuntu版については、メインスレッドに渡すデータはコピーして渡す事で、デコード等の処理スレッドでは、メインスレッドでの描画が終わるのを待たずに、次フレーム用の処理を行える様にした。その結果として、次バージョンでは、他OS用クライアントと比べても、多分、遜色ないくらいの処理速度で動作する様になった筈だ。Adsense)サービスを利用しています。使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。パートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。