端末で縦分割時のスクロールが遅い

Kazuhiro YOSHIKAWA @yoshikaw

なるほど、tmuxは出力をバッファリングしているのか。こういう情報はなかなか紹介記事では触れられないよな。少し違うけど #gnu_screen も分割時（とくに縦分割時）に描画のパフォーマンスが悪いときがあったけど http://bit.ly/du33Uu で改善されて感動した。

いわもと こういち @ttdoda

@yoshikaw 最近のscreenでは改善されているのですね。古めのを使っていて気付きませんでした。私が問題にしていたのも多分同じ事です。

いわもと こういち @ttdoda

@yoshikaw vt100やxtermの機能の関係で縦分割するとスクロール時にウインドウ全体を書き換えないといけないので、一行スクロールする毎に画面を書き換えるのと、複数行のスクロールをまとめて一回の更新で済ますのとで大きく違うという事でした。

Kazuhiro YOSHIKAWA @yoshikaw

@ttdoda #gnu_screen は2年くらい前からCVS版→SVN版→git版と追いかけていますが、縦分割時はls -lしただけでも明らかにもっさりで、findコマンドなんて打った日には二度と縦分割するかとか思ってました。でも今ならほとんど支障ないレベルだと考えています

Kazuhiro YOSHIKAWA @yoshikaw

@ttdoda 先の改善策では、 #gnu_screen 内部で画面(layout)全体ではなく更新のあった部分のみを再描画するようにしたようですが、vt100やxtermにしてみれば全体更新には変わらない気もしましたが、これがどうして全然違いました。

Kazuhiro YOSHIKAWA @yoshikaw

一時期縦分割の描画は遅かったですが、だいぶ改善されましたよ。 RT @doudemoegan: 縦分割に不満があってtmuxに逃げていたんだけどかなりいい具合になってるなぁ。もどるかな。 - これからの「GNU Screen」の話をしよう http://t.co/isYaVUD

saitoha @kefir_

現代のソフトウェア端末の文脈で、ほとんどのひとが速度に不満を感じるのは、縦分割時のスクロール処理じゃないかなあ。DEC端末は縦分割のスクロールリジョンを切れない(横はできる)ので、いちいち書き直すコントロールシーケンス出してる。縦分割するとガタつきやすいのはそのせい。

Takehiro @takehiro0740

@ShougoMatsu いきなりですみません、itermやterminalでvimを起動する時とmacvimをスタンドアローンで起動する時でスクロールのスピードが全然違うんですが（iterm,terminal内で起動したほうが遅い）何が影響してるかってわかってたりしますか？＞＜

暗黒美無王 dark Vim @ShougoMatsu

@takehiro0740 itermは端末の制御コードを解釈する必要があり、原理的にGVim(MacVim)よりも遅くなります。

Takehiro @takehiro0740

@ShougoMatsu なるほどです、Shougoさんはどのように使われていますか？

暗黒美無王 dark Vim @ShougoMatsu

@takehiro0740 私MacVimではないんで……。ただ、端末のVimだと描画が遅いな、とはよく思います。

Takehiro @takehiro0740

@ShougoMatsu なるほどです！ありがとうございます！

saitoha @kefir_

@takehiro0740 @ShougoMatsu ひょっとして縦分割の影響では。多くの端末が採用しているエミュレーションレベルでは縦分割のスクロールリージョンを切る制御コマンドがありません。縦分割時の縦スクロールでは最低でも該当領域の書き直しになります。

暗黒美無王 dark Vim @ShougoMatsu

@kefir_ そうですね。効率が悪そうです。

saitoha @kefir_

実際に縦分割時の端末が遅いと言っている人がいるので、VT Level 4より DECLRMM（Left Right Margin Mode）および DECSLRM（Set Left and Right Margins）を召喚してみてはどうだろうか。

saitoha @kefir_

@takehiro0740 ちょっと前にこんなパッチが出ていました。vimの出力バッファ量を増やすもので、端末の実装によっては更新回数の削減が期待できるかもしれません。縦スクロール時にそこがボトルネックになっていればの話ですが。https://t.co/KA0pDeGQ]

Takehiro @takehiro0740

@kefir_ あざす！！！！！(･∀･) みてみます！

暗黒美無王 dark Vim @ShougoMatsu

@kefir_ @takehiro0740 そのパッチは私も見ました。取り込まれるかどうかは今後の議論次第と思いますけど。

saitoha @kefir_

@ShougoMatsu 普通のPCで動かす分には2Kはちょっとすくないかな、と思いますが、端末側で緩衝バッファをつかった最適化のようなものがあると効果は少ないでしょうね。ちなみにGNU Screenなどを噛ませると1Kでブツ切りされたとおもいます。

haru @uobikiemukot

terminalにinput methodを組み込むのってどうなんだろう? あっても良さそうなのに見たことない

saitoha @kefir_

@uobikiemukot yaftに来るのですか？

haru @uobikiemukot

@kefir_ 今は端末とは別個のプログラムとしてinput methodを書いてます．yaftそのものに組み込んでしまうかどうかは未定です

saitoha @kefir_

@uobikiemukot なるほど。確かにこの手のものは変換操作中に消えてしまう部分をどう補完するかというところがネック。uim-fepやlibfepもスクロールリージョンの管理で頑張ってるみたいだけど、厳密にはあれだとまずい状況がありそうです。

haru @uobikiemukot

やっぱ端末上でIMを動かすとき問題なのは変換候補の表示をどうするか．uim-fepはscroll regionを使ってるけど個人的に好きではない．uim-screenみたいにscreenのステータスに表示するというのもあるけど，開発版じゃないと日本語が通らないし

haru @uobikiemukot

sskk+canossaのpopupっぽい表示は画期的．端末エスケープに特定領域の保存・復元の機能があれば似たようなことを簡単にできると思うけど，対応していない端末では動かなくなって汎用性に欠ける