入力遅延で選ぶテキストエディタ

テキストエディタはGNU Emacs, vim (五十音順)を筆頭にいくつかあり、一般には必要な機能や好みによって選択されている。 テキストエディタを選ぶ際にあまり注目されていない要素として、入力遅延がある。 入力遅延とは、キー押下の時刻から、画面に結果が表示されるまでの時刻の差で、これが短いほど反応が良く使用感として好ましい。 入力遅延はOSとテキストエディタを含めたアプリケーションからなるソフトウェア的なものと、キーボードやバスコントローラ、表示デバイスからなるハードウェア的なものの2つの要素から決まる。 本稿では、同一のOS, ハードウェアを用い、GNU Emacs, vim, Kate, Android Studio, VSCode (VSCodium)の入力遅延を測定することで、入力遅延の観点でもっとも快適なテキストエディタを決める。

関連する話題

入力遅延はしばしば競技的な、すなわちランダム要素の少ない、技量を競う、対人のビデオゲームで問題になることがあり、各タイトルでの入力遅延の測定と比較がファンにより行われ、ときにいくつかのタイトルや特定のプラットフォームで問題になることがあった。 こういった問題に関連して、NVIDIA はゲーム向けに入力遅延測定用のキットNVIDIA Latency Display Analysis Tool (LDAT) [nvidia.com]を頒布しており、これはマウス入力から表示までの時間を自動化された形式で測定することができる。 ただし、このキットは専用のトリガー出力があるマウスを用いており、単純な方法でマウス以外の入力装置に応用することができないため、テキストエディタの入力遅延測定にそのまま活用することはできない。

測定方法

ハードウェアの構成

入力遅延を測るためには、キーの押下時刻と、表示時刻を記録する必要がある。 表示装置は液晶ディスプレイ(LCD) LG 24UD58を使用した。 4K解像度での60 Hzの表示に対応した一般的なディスプレイで、PCとDisplayPortで接続した。 キーボードはKeychron K3 の光学スイッチモデルをPCのUSB3ポートに接続した。 Keychron K3 は、USB接続時にポーリングレート1,000 Hz を実現しており、装飾目的でキー押下に連動して発光ダイオード(LED)を発光させるしくみがある。 キーボードのLEDとLCDの表示状態を単一のカメラで撮影することで、キー押下と表示の時刻を単一の時間軸で測定することができる。 カメラはSony α6400 (ILCE-6400)を用い、1080p 120Hz、シャッタースピード1/800秒の設定でビデオ撮影を行った。

今回測定に用いたPCの主なハードウェア構成は下表に記載した。 一般的な、低価格寄りのゲーミングPCに準じた構成だ。

ゲームでの入力遅延の測定では、しばしばキー押下に連動してアナログビデオ信号の赤、青、緑の3チャンネルのうち一つを落とし、画面全体の色の変化と表示の変化までの時刻をビデオキャプチャで測定する方式が使われる。 この方法では、表示装置またはビデオキャプチャに起因する遅延時間が、キー入力と実際の表示の両方にかかるため、表示装置によらず一定の結果が得られる利点がある。 一方、昨今のPCではアナログビデオ出力を得ることが困難になってきていることに加え、キーボードのような入力マトリクスがあるような装置だと、特定のキー押下に連動した信号を取り出すことがシンプルではないことから、今回はこの方式を用いなかった。 また、テキストエディタの種類による入力遅延の比較という目的では、表示装置による定数遅延が入ることは問題にならない。

ソフトウェアの構成

今回遅延時間を測定したエディタを下表にまとめた。

実験環境のOSは代表的なLinuxディストリビューションの一つであるopenSUSE Tumbleweed (x86_64版)を使用した。 Tumbleweedはローリングリリース方式を採用しており、ディストリビューションとしてのリリースは切られず、それぞれのパッケージのバージョンがその時点での最新になる。 測定時点では、Linux Kernel 6.0.10, KDE 5.26.4, X.org 21.1.4といった内容であった。

GNU Emacs, vimはTumbleweedのレポジトリで利用可能だったemacs-28.2-1.1, vim-9.0.0978を利用した。 vimは端末エミュレータの上で使うことになるので、KDEの標準端末のKonsole (konsole-22.12.0-1.1)を用いたが、測定結果の検証のため軽量のターミナルとして人気があるrxvt-unicodeでも測定を行った。 また、高機能なエディタとして、同じくKDEのアプリケーションの一つKate (kate-22.12.0-1.1)の結果も測定した。

純粋なエディタとはいえないものの、テキスト編集に広く用いられているアプリケーションの区分として統合開発環境(IDE)がある。 IDEの代表として、JetBrainsの各種言語向けの製品が人気があるが、その中で簡単に入手可能なものとしてAndroid Studio Dolphin 2021.3.1 Patch 1 (Build #AI-213.7172.25.2113.9123335, built on September 30, 2022)を利用した。 また、Microsoft開発で昨今人気のVSCode系のIDEの代表として、オープンソースビルドであるVSCodium 1.74.0.22342のGitHubに配置されているビルドを使用した。

測定手順

それぞれのエディタで、単一の行に同じ文字mを10回追加する。 キーボード、ディスプレイが同じフレームに映るようカメラを固定し、一連の動作の様子を撮影した。 記録されたビデオのファイルを、ffmpeg を用いて以下のコマンドで各フレームを画像ファイルとして出力した。

ffmpeg -i INPUT.mp4 'OUTPUT-%05d.jpg'

それぞれのキー押下で、LEDが最初に点灯しているフレームの、画像ファイルの名前として得られるフレーム番号をキー押下時間として記録し、mの文字が表示された最初のフレームのファイル名の番号を表示時間として記録した。 この2つの時間の差が入力遅延 (1/120秒単位)となり、ここからミリ秒 (ms)単位での入力遅延を求めた。 1つのエディタにつき10回の測定があるので、その平均と標準偏差を記録した。

測定結果

下図が測定結果で、エラーバーは標準偏差を示している。 emacsとKateが60 fps換算で3フレーム弱の遅延となり、測定方法がキーボードから画面までの遅延を含むことを考えると、今回のハードウェア構成で実現できる最低の遅延にかなり近いと言えそう。 当初、Konsoleの上で動かしたvim の測定結果結果がemacs より遅かったのを不審に思い、urxvt で測定したが結果はKonsoleと同じであった。 Kateで十分な低遅延が実現できていることからも、Konsole-vimの組み合わせの遅延の原因はQtやKDEの描画周りにはなさそうであることが改めて確認できる。

JetBrainsのIDEであるAndroid Studioはvimと同等の入力遅延を実現しており、付加機能の多さを考慮すると非常に優秀と言える。 一方、VSCodium はvimやAndroid Studioと比較して60 fps相当でちょうど1フレーム遅れている。

測定結果の標準偏差に注目すると、カメラのフレームレートである120 fps相当の8.3 ms 前後になっており、どのテキストエディタを使ってもひどく挙動にばらつきが多いということはない。 表示遅延に関しては、絶対的な遅延時間の短さだけでなく、遅延時間が一定であることが快適さにつながることが知られている [1]。 テキストエディタ間の差は小さいものの、その中で、Konsoleとvimの組み合わせはは一番反応速度に一貫性があり、Android Studioが反応速度にばらつきが一番大きかった。 Android Studioを含むJetBrainsのIDEは、Java Virtual Machine (JVM)の上で動いていることが知られており、JVMはガベージコレクション (GC)でときおり処理時間が長くなることが原因かとも考えたが、GCがあるのはGNU Emacsで使用しているLispもVSCodiumで使用しているJavaScriptも同じなので、方式としての本質的な問題とは言えず、実装または別のところにばらつきの問題があるのだろう。 実装上の工夫の例としては、カプコンのゲームエンジンREエンジンでは、フレームレートを保ちながらGCを実現するFrameGCというアルゴリズムが実装されている [2]。 テキストエディタにおいても、フレーム落ちが快適さに影響を与えるのは明らかなので、各種工夫を通して低遅延で一定な入力遅延を実現するような設計が求められているといえるだろう。

むすび

テキストエディタであっても、その設計に応じて入力遅延は異なることが確認できた。 実際の使用感とも一致しており、快適なエディタを使いたいなら入力遅延が短いものを選ぶ必要がある。 私としては、従来メール送受信にもGNU emacsを利用していたのだが、最近はいろいろなこだわりがなくなってきて、日常的に使う中で快適さのあるKateを使用していたが、その理由の一部が入力遅延が低いことにあったことが確認できた。

vim は雰囲気から受ける印象に反して、入力遅延は長めであることが分かった。 また、高機能なIDEであっても、JetBrainsの製品はvimと同等の入力遅延を持つ一方、VSCodiumでは入力遅延は大きく、使用感に影響を及ぼすこともありそうだ。

入力遅延をもとにテキストエディタを選ぶなら、GNU emacsまたはKateを利用するべきだ。

高フレームレートに対応したモニタを用いることで、ウインドウシステムのダブルバッファ起因の遅延は短縮することができそうである。 今後、こういった低遅延を謳う製品でのテキストエディタのふるまいを検証する必要がある。 また、Linux/X11の組み合わせ以外のウインドウシステムで入力遅延がどのように変化するかも確認していきたい。

2022-12-18 初稿

参考文献

1. 森口明彦, 芯（シン）・遅延対策2020 ～ヒトのスペックから紐解かれる、安定性重視とフレームレートのベストプラクティス～. CEDEC 2019. 2019-09-05. [cedil.cesa.or.jp]
2. 石田智史, ラピッドイテレーションを実現するRE ENGINEの設計. Game Creators Conference '17. 2017-02-18. [gc-conf.com].