Repository navigation
GUI keyboard repeat rate suffers with many long lines #1259
Description
Steps to reproduce
- Open MacVim (
mvim --clean) - Create a line 80 characters long (
80ii<Esc>) - Go to beginning of line (
0) - Hold down 'l' and time how long it takes to get to the end of the line (for me, about 3 seconds)
- Delete this line (
dd) - Create a line 700 characters long (
700ii<Esc>) - Make 90 copies of this line (
yy90p) - Go to column one, row one (
1G0) - Hold down
land time how long it takes to get to column 80 (for me, about 6 seconds)
(This affects insert repeat rate as well as cursor motion.)
(Also, I don't think this was a problem before the recent update to 9.0, but I could be wrong.)
Expected behaviour
The repeat rate shouldn't be affected by the data in the buffer.
Version of Vim and architecture
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jul 25 2022 08:23:03) macOS version - x86_64 Included patches: 1-65
Environment
MacOS 11.6.4
MacVim GUI
How MacVim was installed
Internal update; originally installed from download
Logs and stack traces
No response
Vim configuration where issue is reproducable
No response
Issue has been tested with given configuration
- by running MacVim.app from GUI macOS interface
- by running vim/gvim/etc installed by MacVim
- by running other versions of vim (e.g. /usr/bin/vim)
Issue has been tested with no configuration
- by running
mvim --clean(orgvim, supplied by MacVim distribution) - by running
vim --clean(in terminal, supplied by MacVim distribution) - by running
vim --clean(in terminal, other suppliers, e.g. /usr/bin/vim)
Other conditions
- The both Homebrew packages "vim" and "macvim" are installed
Activity
ychin commentedon Aug 4, 2022
I think this is a general rendering performance in our text renderer, and has been the case since before the latest 9.0 update (quick testing confirmed that as well). See #858.
I filed a new issue (#1262) to track this but for now I'm closing this because this isn't a bug per se, but a general rendering performance issue.
One related issue here is that MacVim would only get repeated key input when it's handling the
keyDownevent, but it doesn't know how many keys it should get. If it's blocking on the main thread (which is the case here due to slow rendering performance), it will cause the observed number of key repeats to be fewer (hence this bug). By moving to Metal, in addition to better performance, the rendering is also going to be done asynchronously which should alleviate this issue.ychin commentedon Aug 6, 2022
Actually, looking into it, I think MacVim has special logic in dropping repeated keys when it's lagging behind, which I do agree feels wrong. Let me think about it more.