読者です 読者をやめる 読者になる 読者になる

B(ug)log

開発とかぼやきとかLINEスタンプとか http://line.me/S/sticker/1245783 職探し中

空間ナビゲーション実装(その 3)

Windows 上で空間ナビゲーションを実現したい - B(ug)log
空間ナビゲーション実装(その 2) - B(ug)log

続きです。フォーカス移動するまでに時間がかかっていた (200-300ms くらいかかってた) のが昨日の実装です。

今日は結論から

f:id:u338steven:20160502201411g:plain

フォーカス移動アニメーションが追いつかないくらい速くなりました。(20-300msくらい)

f:id:u338steven:20160502201443p:plain

やったね。

どうしてこうなった

ブラウザ の DOM などと比較すると UIAssistant (というか Windows Automation API) は、全要素の取得のコストが高いという特徴があります。これが昨日までボトルネックになっていました。しかし、全要素の取得を完全に避けることはできないので、ボトルネックとなる箇所をなるべく通らなければいいという考えで対処しました。以下のようにワンクッション置くことで、条件によっては速く移動できるわけです。

  1. 現在フォーカスのあっている要素と兄弟関係になっている要素から移動先の候補を探す
  2. 上記の候補が見つからなかったら、全要素から移動先の候補を探す(ボトルネックになっている処理)

兄弟関係の要素から見つからなかった場合、現状の実装だとワンクッションの処理分遅くなってしまいます。が、すでに評価された要素の場合は処理をとばすようにすれば、そんなに遅くはならないはずです。1 ループの条件分岐分の処理時間くらいイマドキ誤差ですよ誤差(だといいな)

このあとどーすんの?

さらにクッションを増やすかどうか検討します。別の考えとして、発想を逆転させるんだっていうのもアリです。つまり、逆方向のボトムアップ式な考えで、現在フォーカスがあたっている要素から親の要素を取得して、その親の兄弟の中から探すのを繰り返す形式。親の要素の取得もそれなりに高コストなので速度比較は必要になりますが……。(foobar2000 に 600 曲くらいぶちこんで空間ナビゲーションで移動しようとしたら、全要素取得するロジックに入ってしまった場合、移動に 2 秒くらいかかりました。まだまだ工夫が必要です)