GUI keyboard repeat rate suffers with many long lines

[wfaulk]

Steps to reproduce

1. Open MacVim (mvim --clean)
2. Create a line 80 characters long (80ii<Esc>)
3. Go to beginning of line (0)
4. Hold down 'l' and time how long it takes to get to the end of the line (for me, about 3 seconds)
5. Delete this line (dd)
6. Create a line 700 characters long (700ii<Esc>)
7. Make 90 copies of this line (yy90p)
8. Go to column one, row one (1G0)
9. Hold down l and 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

• [X] by running MacVim.app from GUI macOS interface
• [X] by running vim/gvim/etc installed by MacVim
• [X] by running other versions of vim (e.g. /usr/bin/vim)

Issue has been tested with no configuration

• [X] by running mvim --clean (or gvim, supplied by MacVim distribution)
• [X] by running vim --clean (in terminal, supplied by MacVim distribution)
• [X] by running vim --clean (in terminal, other suppliers, e.g. /usr/bin/vim)

Other conditions

• [ ] The both Homebrew packages "vim" and "macvim" are installed

[ychin]

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 keyDown event, 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]

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.