[vim/vim] perf(gtk3-wayland): deferred dirty redraw (PR #20528)

dezza

unread,

Jun 14, 2026, 11:25:21 PM (11 days ago) Jun 14

to vim/vim, Subscribed

Implements a dirty rect box for gtk3 with wayland backend.

Instead of constantly pumping gtk3 loop between keypress, which almost always have a queued draw due to especially

gui_gtk_draw_string_ext
gui_mch_clear_block

.. or gui_mch_delete_lines, gui_mch_insert_lines when scrolling.

Instead we re-use gui_mch_update, which before pumped redraws during key-repeat like pgup for scrolling, this caused tearing, partial redraws.

In gui_mch_update we now explicitly call gui_mch_flush for wayland, where a wl_flush function flushes the dirty rect.

We gate that flush checking for a queued redraw in gdk/gtk3.

This prepares a redraw for g_main_context_iteration below.

The result is, that scrolling is fast, mostly smooth and cpu usage lowered significantly; because key input, especially with continous- key repeat with a scroll key such as pgup/c-b does not- simultaneously pump excessive redraws from the micro-redraws queued by gui_gtk_draw_string_ext etc.

This aligns with intended use of gui_mch_update on x11, but is mostly a symptom of wayland being asynchronous, whereas x11 and vim is largely stateful, imperative and immediate.

Inside gui_mch_wait_for_chars it triggers
g_main_context_iteration constantly both at idle or with key input. and finally reaches gui_mch_update, even if a key is held.

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/20528

Commit Summary

cfaea1b perf(gtk3-wayland): deferred dirty redraw

File Changes

(1 file)

M src/gui_gtk_x11.c (95)

Patch Links:

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

dezza

unread,

Jun 14, 2026, 11:33:48 PM (11 days ago) Jun 14

to vim/vim, Subscribed

dezza left a comment (vim/vim#20528)

Leaving this as draft for the moment. It is not thoroughly tested, but it is a major milestone in performance on gtk3 with wayland.

It is now very much acceptable, even with 4k, hidpi, small font and integer scaling.

If you want to test this is the best way to reproduce slow gtk3;

Hidpi 2160p+ display
Vertical screen
Small font 11-12pt

Find a large file with many highlight groups/syntax from left to right.
Hold <PageDown>|CTRL-F from top to bottom and inversely <PageUp>|CTRL-B from bottom.

Note that scrolling from bottom to top is significantly more intensive, due to vim's architecture with syntax and will highlight the performance shortcoming even more.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

dezza

unread,

Jun 21, 2026, 10:17:08 PM (4 days ago) Jun 21

to vim/vim, Subscribed

dezza left a comment (vim/vim#20528)

@chrisbra does this align with the intended use of lazyredraw ? 9d7b53f

If not, I will rethink it or remove it entirely.

Could be useful if someone has an extraordinarily large screen, or if for other reasons it became slow again.

The scroll and snap redraw feels right to me, a good compromise.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jun 22, 2026, 3:55:03 PM (3 days ago) Jun 22

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#20528)

@chrisbra does this align with the intended use of lazyredraw ? 9d7b53f

I don't think this fits. The use case of lazyredraw it to speed up non-typed editing (like macro recordings and mappings). It's not so much meant for interactive use cases.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

dezza

unread,

Jun 22, 2026, 4:06:36 PM (3 days ago) Jun 22

to vim/vim, Subscribed

dezza left a comment (vim/vim#20528)

@chrisbra does this align with the intended use of lazyredraw ? 9d7b53f

I don't think this fits. The use case of lazyredraw it to speed up non-typed editing (like macro recordings and mappings). It's not so much meant for interactive use cases.

Thanks! This was news to me too when I read the help - I know some have it permanently enabled, I'll just revert it. Still haven't found issues.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

dezza

unread,

10:44 AM (3 hours ago) 10:44 AM

to vim/vim, Subscribed

dezza left a comment (vim/vim#20528)

@chrisbra I think this is ready now, been enjoying it a lot. If not, then the only way of testing is asking others to try.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward