画面描画が遅くなる #994

Open
koron opened this Issue Dec 14, 2016 · 4 comments

Projects

None yet

2 participants

@koron
Member
koron commented Dec 14, 2016 edited

報告の内容

Windows 10 の gvim において、ウィンドウ(正確には Vim text area) の下端が、ある線を超えると画面描画が遅くなります。その度合は様々な条件で異なりますが、最終的なトリガーはそこでした。

また ある線 はタスクバー(の上端の位置?)に依存しているようです。1920x1200のモニターにおいて、タスクバーを常時表示したデフォルトの状態ではウィンドウの下端がY座標 1130 以上になった場合に症状が発生していたのですが、タスクバーを自動的に隠す設定に変えた際にはその閾値が 1170 に引き上がりました。

遅くなるのが顕著な条件は以下のとおりです。実際にどのくらい遅くなるのかは計測していませんが、これらの条件を満たすと、一度スクリーンがクリアされた後に行単位で描画されているのを目視で確認できるほどです。

  • DirectXによる描画をしている (:set renderoptions=type:directx)

  • vsplit 状態

  • Ctrl + F のような順方向の1画面スクロール実行時(逆方向では観測できない)

  • Vimのウィンドウの下端を、画面下部のタスクバーの上端に近い場所に配置する

    (逆にそこから離す(=上に移動させる)と症状は観測されなくなる)

加えて以下の設定がこの症状に影響を与えないこと、は確認済みです。

  • ウィンドウの影の有無
  • タスクバーの背景が半透明かどうか

また DirectX を使わない pure GDI による描画においても、 DirectX 使用時ほどではないですが描画遅延は発生しているようです。

とりあえず気になって調査したので記録のためにissue化しておきました。

Vimのバージョン

  • 8.0.95 (+kaoriya)
  • 8.0.133 (vim-win32-installer)

OSの種類/ディストリ/バージョン

  • Windows 10 Pro 64bit (バージョン 1607)

その他

将来の調査に際しては、以下の点がいとぐちになる可能性があります。

  • ウィンドウの下端の位置がトリガーになっている
  • pure GDIでも発生している
  • DirectXのほうが相当に速度低下が激しい
  • columns の値には関係なく :vsplit すると顕著になる

またこの症状は、グラフィックボード(RADEON HD7700系)を積んだデスクトップPCと、CPU (Core m5) に内蔵のGPUのノートPC、2つで確認しました。よってグラフィックボードやドライバーへの依存はないと推測されます。

@koron koron self-assigned this Dec 14, 2016
@koron
Member
koron commented Dec 15, 2016

これ、描画そのものよりもクリアのほうに時間かかってるかもしれない。

@koron
Member
koron commented Jan 6, 2017

vsplit していなければさほど遅くない例

vsplitしていなければさほど遅くない

vsplit しちゃうとえらく遅い例

vsplit しちゃうとえらく遅い例

@mattn
Member
mattn commented Jan 6, 2017

ずいぶん目立ちますね。分割右側は再描画掛かってないすね。

@koron
Member
koron commented Jan 7, 2017

なんか不思議ですよね。
よく見てみると描画その最寄りもクリアのほうが遅いように見えてきます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment