Fix rendering performance issue when using :version or echo commands #840
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes 10.14 Mojave's CoreText renderer taking a long time to render :version / :ls / :! / :echo or similar commands. This issue happened because the way Vim echos the output of those commands is by issuing a draw calls in the pattern of "delete 1 line, draw some text, delete another line...". Each line delete causes the renderer to do a scroll. The pre-Mojave renderer relies on calling scrollRect: but this doesn't work in Mojave anymore since that function is deprecated and doesn't work in layer-backed views (which are now mandatory). The new renderer's scroll implementation is a lot slower since it's doing image blits on CPU. The fix is to implement a draw command optimizer that pre-processes the draw calls first. It works by batching together all the "delete 1 line" calls and combine into a single "delete N lines" call and put that in the beginning, and fixing up all the other draw string command so they draw to the right line instead of needing to be scrolled up. This makes :version or the other calls feel instaneous now. This fix is ultimately a hack and an intermediary solution before the renderer can be replaced (since the slow CPU scrolling causes normal usage to feel sluggish as well) by a GPU-based renderer and/or a glyph-based one that caches the state of the texts so repeated scrolling can be done by shuffling the glpyh data around instead of an actualy image blit. Fix macvim-dev#815
ychin
force-pushed
the
cmd-echo-perf-fix
branch
from
ddc869f
to
b4014c8
Compare
|
For what it's worth, this has made a massive perceived improvement to rendering, so thank you! I still look forward to the GPU rendering world, but thanks for this! |
ychin
added a commit
to ychin/macvim
that referenced
this pull request
Feb 4, 2019
Vim patch 8.1.873 Targets macOS 10.8+ General: - MacVim binary is now signed by a Developer ID (macvim-dev#517). This makes it easier to download and run the app without security warnings. - This also fixes an issue where invoking external programs via `:!open` was slow in Mojave. macvim-dev#763 - Ruby version has been updated from 2.5 to 2.6. Fixes: - Scrollbars are no longer misplaced when resizing window macvim-dev#827 - Fix rendering performance issues for commands (e.g. `:version`, `:echo`, or `:!`) that echo text in Mojave macvim-dev#840 - MacVim now properly asks for permission to use AppleEvent (ODB Editor Suite requires that to work) macvim-dev#822 - Fix borderless window mode in pre-Mojave versions macvim-dev#828 Script interfaces have compatibility with these versions: - Lua 5.3 - Perl 5.18 - Python2 2.7 - Python3 3.7 - Ruby 2.6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes 10.14 Mojave's CoreText renderer taking a long time to render
:version/:ls/:!/:echoor similar commands.This issue happened because the way Vim echos the output of those commands is by issuing a draw calls in the pattern of "delete 1 line, draw some text, delete another line...". Each line delete causes the renderer to do a scroll. The pre-Mojave renderer relies on calling
scrollRect:by:but this doesn't work in Mojave anymore since that function is deprecated and doesn't work in layer-backed views (which are now mandatory). The new renderer's scroll implementation is a lot slower since it's doing image blits on CPU.The fix is to implement a draw command optimizer that pre-processes the draw calls first. It works by batching together all the "delete 1 line" calls and combine into a single "delete N lines" call and put that in the beginning, and fixing up all the other draw string command so they draw to the right line instead of needing to be scrolled up. This makes
:versionor the other calls feel instaneous now.This fix is ultimately a hack and an intermediary solution before the renderer can be replaced (since the slow CPU scrolling causes normal usage to feel sluggish as well) by a GPU-based renderer and/or a glyph-based one that caches the state of the texts so repeated scrolling can be done by shuffling the glpyh data around instead of an actualy image blit.
Fix #815