Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizing the buffer synchronization #24

Open
mickael-menu opened this issue Feb 21, 2023 · 1 comment
Open

Optimizing the buffer synchronization #24

mickael-menu opened this issue Feb 21, 2023 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@mickael-menu
Copy link
Owner

mickael-menu commented Feb 21, 2023

ShadowVim currently has a very straightforward approach to synchronizing changes between Neovim and Xcode. It is not very performant nor visually appealing.

⚠️ Fixing this is not high on my priority list, as I'd like to integrate more Nvim features first (e.g. command line). If you're enjoying ShadowVim and wish to give back, please consider giving a hand on the following areas of improvements.

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:

private func updateUIPartialLines(with event: BufLinesEvent) throws {

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:

// Optimizes changing only the tail of a line, to avoid refreshing the whole
// line which triggers selection artifacts.
private func updateUIOneLine(at lineIndex: LineIndex, in element: AXUIElement, content: String, replacement: String) throws {

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
@mickael-menu mickael-menu added enhancement New feature or request help wanted Extra attention is needed labels Feb 21, 2023
@mickael-menu mickael-menu pinned this issue Feb 21, 2023
@mickael-menu
Copy link
Owner Author

#43 introduces several optimizations:

  • buf_lines_events are applied on an internal buffer and a diff is computed when receiving a flush UI event. This essentially solves the problem exhibited above without explicitly coalescing the buf_lines_events.
  • 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant