Optimizing the buffer synchronization
mickael-menu opened this issue · 1 comments
ShadowVim currently has a very straightforward approach to synchronizing changes between Neovim and Xcode. It is not very performant nor visually appealing.
Character instead of line-wise changes
The main reason for the visual artifacts is that Neovim sends line-wise change events. So every time you do a change, ShadowVim will update whole lines in Xcode.
lines.mov
A possible fix would be to resolve character indexes instead of line ones to apply a lines change event, here:
I already added a basic optim to perform character-wise changes only when modifying the end of a line, to make it more bearable when inserting a lot of text:
ShadowVim/Sources/Mediator/Buffer/BufferMediator.swift
Lines 288 to 290 in d745f68
Grouping line changes
When modifying several lines of changes natively from Xcode (e.g. after inserting an Xcode snippet or pasting content from the pasteboard with ⌘V), they are applied line by line back to Nvim, after computing a diff from the current Nvim state.
This is straightforward, thanks to CollectionDifference
. A downside, besides the general performance, is that Nvim registers this as a lot of separate change events instead of a compound one. This is very visible when undoing the change.
For example in the following video, I'm inserting an Xcode snippet, then hit u
to undo the change, then C-r to redo it. An improvement could be to analyze the CompletionDifference
to group consecutive line changes and send them to Nvim in one go.
changes-ui.mov
Grouping Neovim's buf_lines_event
Sometimes Neovim sends in one go multiple buffer change events (buf_lines_event
) changing the same line multiple times (character by character). You can see this when triggering Neovim's completion with C-n, like in the following video.
ShadowVim applies the changes in order, which is of course useless and inefficient in this case. A possible optimization would be to coalesce events changing the same lines and received in a really short span.
To know when to stop coalescing events, we can listened to the flush
redraw
event in the UI protocol.
buf_lines_event.mov
#43 introduces several optimizations:
buf_lines_event
s are applied on an internal buffer and a diff is computed when receiving aflush
UI event. This essentially solves the problem exhibited above without explicitly coalescing thebuf_lines_event
s.- UI line diffs are partially coalesced, when:
- Consecutive lines are added/deleted.
- A single line is both added and modified (basically when entering a character).