:version takes about a second to display MacVim version info #815
Comments
|
It's related to the new Mojave renderer. Will need to take a look. Probably some de-generate case with tons of text draw calls all done at once. |
|
I notice a delay too, but it's definitely not one second. It's much shorter (like less than .25 seconds). I had to run it a few times in comparison to the console version to even be sure that a delay existed. Either way, it should be fixed. FWIW, I don't have any of the scripting languages compiled in. |
|
It's also really bad if you run any sort of The new renderer needs some pretty significant performance improvements I think. Random thought - would there be any way we could copy the implementation from like iTerm2 or something? I imagine it's open source, it's pretty damn fast, could be really nice, but I imagine not a simple drop in replacement either. |
|
As tagged in this issue, there should be some basic improvements to When the new renderer was implemented it was mostly to make Mojave work again to unblock people so I didn't really have time to go and improve it, so now that it's somewhat usable that will be next. I have looked at iTerm2 before and it's not a drop-in replacement and their Metal renderer doesn't support certain features like ligatures or transparency. My gut feeling from browsing through it is it would take more time to use it as well as re-adding features we have always supported than writing a new Metal renderer from scratch. The question is whether we want to completely accelerate the text drawing using a glyph cache (which would be faster but harder to support things like ligatures) or simply use the GPU to accelerate scrolling and compositing. |
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 anyway since that function is deprecated and doesn't work in layer-backed views (which are now mandatory). The new renderer's scrollRect: is a lot of slow 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
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 of slow 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
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
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
|
This issue should now be fixed. It's not a general fix for the renderer but will make commands that echo as fast as before now (e.g. |
I'm on MacOS 10.14.2 and Xcode 10.1 and have configured MacVim as follows:
When you issue
:versioncommand in the GUI , there is now a noticeable delay before the command displays the version information. Command line version prints the version info instantly.This is a regression from versions built with macOS 10.13 SDK.
The text was updated successfully, but these errors were encountered: