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
It appears that scroll performance on retina screens is significantly worse that non-retina screens. It is also much worse when there's only 1 document open and the app is full screen, vs have multiple documents open (and thus far less width for each document).
I can look into making some videos of the performance differences, but it really is mostly an issue when in full screen.
I have the 5k iMac and it is REALLY bad when running full screen with a single document open. Are there any places that draw performance could be optimized?
I'll look to make a video tonight, but it will be from a 5k imac screen, so rather large. I think the issue has something to do with how wide the document is. If I split the screen a bunch, even with the same file, performance definitely improves.
I also experience this issue on mbp 2017, it's better compared to terminal but still laggy. The 5k video provided in the answer above is a great example
I don't really know Objective-C, however doing a little digging I did notice a couple additional things to add to this issue:
The issue appears when using non-native full screen.
The issue seems to surface whenever cgLayerEnabled is set to true in MMCoreTextView. Based on my experiments, that value is normally false in native full screen or windowed mode.
For reference, I use these MacVim settings:
I did some poking around in the drawRect function of MMCoreTextView, and sure enough, when using non-native full screen, cgLayerEnabled becomes true and we get very sluggish performance (on large, high pixel density screens):
is super efficient as it only updates parts of the screen that are necessary unlike non-native full screen that re-renders the entire document, killing performance on 5k retina monitors.
When I tried forcing that codepath on non-native full screen, i would just see black, unless I scrolled or did something and then would temporarily see region'd updates to the screen before going black in the next frame.
Looks like the only way to fix this would be for non-native full screen to use the batchDrawData function somehow, but that gets a bit out of my league.
For 10.14 (Mojave), #757 has introduced a new renderer that doesn't use CGLayer and it's used across the board including non-native fullscreen. It's faster than the old CGLayer renderer (which used to be used by non-native fullscreen), but a little slower than the old normal non-fullscreen renderer. If you are not satisfied with the new renderer's performance, use #796 to track.
For 10.13 (High Sierra) or below, this is a wontfix. Non-native fullscreen uses CGLayer and it's slow. You can either upgrade to 10.14 or use native fullscreen if the performance is too slow. The fix for #796 may be backported to 10.13 but that may not work if it involves using newer APIs.
Activity
jordwalke commentedon May 16, 2017
Do you have a ligature font with ligatures enabled by any chance?
amadeus commentedon May 16, 2017
I don't think so? I'm using Source Code Pro. What would be the setting to disable ligatures?
jordwalke commentedon May 16, 2017
You'd have to go out of your way to enable it. Do
:set nomacligato disable them.amadeus commentedon May 16, 2017
Ahh yeah, it's off by default then for me.
amadeus commentedon May 16, 2017
I'll look to make a video tonight, but it will be from a 5k imac screen, so rather large. I think the issue has something to do with how wide the document is. If I split the screen a bunch, even with the same file, performance definitely improves.
amadeus commentedon May 18, 2017
As promised, here's a link to a video showing off the performance differences:
video
As an FYI, all 'scrolling' was done by holding down
<c-e>or<c-y>.Also I just split my current file by doing
<c-w>vamadeus commentedon Aug 9, 2017
Just a bump on this, any ideas on why it might be performing like so and could it be improved?
StaverDmitry commentedon Nov 27, 2017
I also experience this issue on mbp 2017, it's better compared to terminal but still laggy. The 5k video provided in the answer above is a great example
amadeus commentedon Nov 27, 2017
I also want to add an additional video - of nearly the same experiment but using a non retina, or a 1x monitor:
Notice how there's almost no difference in scroll speeds. This leads me to believe there's something that gets wildly inefficient on retina displays.
Also another anecdote I think I've seen as well - native full screen performs a bit better than non-native full screen.
I guess to be fair, retina is pushing 4x the pixels, but still, it would be REALLY nice to improve this experience.
amadeus commentedon Apr 30, 2018
I don't really know Objective-C, however doing a little digging I did notice a couple additional things to add to this issue:
The issue appears when using non-native full screen.
The issue seems to surface whenever
cgLayerEnabledis set to true inMMCoreTextView. Based on my experiments, that value is normally false in native full screen or windowed mode.For reference, I use these MacVim settings:
I did some poking around in the
drawRectfunction ofMMCoreTextView, and sure enough, when using non-native full screen,cgLayerEnabledbecomes true and we get very sluggish performance (on large, high pixel density screens):macvim/src/MacVim/MMCoreTextView.m
Lines 607 to 650 in 27bdb64
From what I can tell, the non
cgLayerEnabledcodepath (aka theelsepath):macvim/src/MacVim/MMCoreTextView.m
Lines 642 to 649 in 27bdb64
is super efficient as it only updates parts of the screen that are necessary unlike non-native full screen that re-renders the entire document, killing performance on 5k retina monitors.
When I tried forcing that codepath on non-native full screen, i would just see black, unless I scrolled or did something and then would temporarily see region'd updates to the screen before going black in the next frame.
Looks like the only way to fix this would be for non-native full screen to use the
batchDrawDatafunction somehow, but that gets a bit out of my league.CodeMonkeyKevin commentedon Jun 30, 2018
Any update on this.
ychin commentedon Dec 20, 2018
I'm closing this issue.
For 10.14 (Mojave), #757 has introduced a new renderer that doesn't use CGLayer and it's used across the board including non-native fullscreen. It's faster than the old CGLayer renderer (which used to be used by non-native fullscreen), but a little slower than the old normal non-fullscreen renderer. If you are not satisfied with the new renderer's performance, use #796 to track.
For 10.13 (High Sierra) or below, this is a wontfix. Non-native fullscreen uses CGLayer and it's slow. You can either upgrade to 10.14 or use native fullscreen if the performance is too slow. The fix for #796 may be backported to 10.13 but that may not work if it involves using newer APIs.