You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
:version takes about a second to display MacVim version info #815
When you issue :version command 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.
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 :! command that has a lot of output - for example a :!git pull that then spawns a ton of lines of text. I've had the entire app become completely unresponsive for about 10 seconds due to this.
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 :version/:! by next snapshot (154), just to alleviate the situation, and I'm hoping to be able to revamp the renderer by snapshot-155.
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 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. :ls, :version, :!, :echo).
Activity
ychin commentedon Dec 11, 2018
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.
chdiza commentedon Dec 11, 2018
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.
amadeus commentedon Dec 20, 2018
It's also really bad if you run any sort of
:!command that has a lot of output - for example a:!git pullthat then spawns a ton of lines of text. I've had the entire app become completely unresponsive for about 10 seconds due to this.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.
ychin commentedon Dec 21, 2018
As tagged in this issue, there should be some basic improvements to
:version/:!by next snapshot (154), just to alleviate the situation, and I'm hoping to be able to revamp the renderer by snapshot-155.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.
Fix rendering performance issue when using :version or echo commands
Fix rendering performance issue when using :version or echo commands
Fix rendering performance issue when using :version or echo commands
Fix rendering performance issue when using :version or echo commands
ychin commentedon Feb 3, 2019
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.
:ls,:version,:!,:echo).