スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

1.5秒バッファ

結局音声と画像の同期を諦めて1.5秒程度のバッファをもうけることにしました。
バッファ残量0~1をうろうろするようなギリギリのバッファ量でそこそこ頻繁にバッファリングが発生する感じ。
しかしぶちぶち切れる感じは初期に比べればかなり軽減できており、ときに音声ボード並のつなぎを見せることも。

画質の落し方のオプションが増えたというのは前の記事で書きましたが、ここでまたひとつ問題が浮上。
サーバー側では70KB固定なので、どっちにしろ変更箇所が沢山ある場合は結局70KBいっぱいいっぱいDLされてしまい、更新スピードは変化しないというもの。ただし一回のDLでほとんどの箇所の更新を終えるので体感速度は若干上がりますが、画質は悪いのであんまりお得感がない。

そこでやはりDLサイズ制限をアプリ側で指定可能にできるべきだと思う。
それで初めて画質を落とす価値が体感できるだろうし、表示は最低限で良い、なによりサクサク感が大事って人には使い道のあるものなのかなぁ、と。


あと更新が速いのはいいけどクリック後すぐの画像が取得されてもあんまりそのときの画像っていらないんですよね。
たとえばウィンドウを閉じたボタンを押したとき、ウィンドウが消えていくアニメーションが表示されるときがあると思います。この場合さらにウィンドウが消えたあとの状態の画像も取得しないといけません。ペーストするときなどならペーストした瞬間の文字列が挿入される直前の画像を取得してしまう。この無駄な中間フレームの更新により結果としてほしい結果を得るのが遅れてしまう。

そこでイベントを送信した場合にはサーバーは0.5秒まってからキャプチャし、アプリ側に結果を送信するというものを考えてみた。小さな作業ならば0.5秒もあれば完全に反映されるはず。一件レスポンスが悪くなりそうだけどその中間フレーム取得の手間がなくなるので、クリックした最初のフレームで反映された画像を取得できるとしたら、結果としては、 (DL一回分-0.5)秒くらい早く欲しい結果が得られる。はず。


まだまだiRemoteは未完成だなぁ。


■追記
0.5秒待つってのは長すぎてだめだった。たしかに一発目で更新結果を得られるが、即応して欲しいものに関しても0.5秒待つのでかえって遅くなってしまったという印象。でもちょっとはあった方が良さそうというのもあってバランスが難しい。

■さらに追記
とりあえず0.2秒にしてみた。ウィンドウを閉じるときには中間フレームはひろうけど…微妙な機能になってきた。。
DLサイズ設定項目はアプリ側に移動した。10KB落としてみたがやはり若干のレスポンス向上が見られる。
そこでまた問題が。
iRemoteの場合はカーソルを中心に螺旋状に優先度をふってるために表示されている部分が更新遅れがあっても画面外の部分はかなり更新が終わっている場合が結構ある。
優先度振り分けを見直してなによりも表示されている部分を優先にしたい。

コメントの投稿

非公開コメント

Go To 物置。
プロフィール

書いてる人:つん

まったりのんびり。書いてる人の息抜きブログです。

多分連絡先↓
metal_tsun@yahoo.co.jp

カテゴリー
リンク
月別アーカイブ
バロメーター
Java歴:2005年2月から今まで。
3DCG歴:2005年8月から数年。
C歴:2006年4月から今まで。
VB歴:2007年3月からちょっと。
Delphi歴:2007年3月からちょっと。
PIC歴:2007年5月から数年。
イラスト歴:2007年12月から今まで。
DTM歴2008年2月からちょっと。
PHP歴2008年4月からちょっと。
C++歴2008年4月から今まで。
C#歴2009年1月から今まで。
Objective-C歴2009年4月から今まで。
CSS歴2012年5月から今まで。

ブログ開始日2005/10/11


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。