Scroll Performance on Retina Screens

[amadeus]

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?

Video Example

[jordwalke]

Do you have a ligature font with ligatures enabled by any chance?

[amadeus]

I don't think so? I'm using Source Code Pro. What would be the setting to disable ligatures?

[jordwalke]

You'd have to go out of your way to enable it. Do :set nomacliga to disable them.

[amadeus]

Ahh yeah, it's off by default then for me.

[amadeus]

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]

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>v

[amadeus]

Just a bump on this, any ideas on why it might be performing like so and could it be improved?

[StaverDmitry]

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]

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]

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):

macvim/src/MacVim/MMCoreTextView.m

Lines 607 to 650 in 27bdb64

	- (void)drawRect:(NSRect)rect
	{
	NSGraphicsContext *context = [NSGraphicsContext currentContext];
	[context setShouldAntialias:antialias];
	if (cgLayerEnabled && drawData.count == 0) {
	// during a live resize, we will have around a stale layer until the
	// refresh messages travel back from the vim process. We push the old
	// layer in at an offset to get rid of jitter due to lines changing
	// position.
	[cgLayerLock lock];
	CGLayerRef l = [self getCGLayer];
	CGSize cgLayerSize = CGLayerGetSize(l);
	CGSize frameSize = [self frame].size;
	NSRect drawRect = NSMakeRect(
	0,
	frameSize.height - cgLayerSize.height,
	cgLayerSize.width,
	cgLayerSize.height);
	CGContextRef cgContext = [context graphicsPort];
	const NSRect *rects;
	long count;
	[self getRectsBeingDrawn:&rects count:&count];
	int i;
	for (i = 0; i < count; i++) {
	CGContextSaveGState(cgContext);
	CGContextClipToRect(cgContext, rects[i]);
	CGContextSetBlendMode(cgContext, kCGBlendModeCopy);
	CGContextDrawLayerInRect(cgContext, drawRect, l);
	CGContextRestoreGState(cgContext);
	}
	[cgLayerLock unlock];
	} else {
	id data;
	NSEnumerator *e = [drawData objectEnumerator];
	while ((data = [e nextObject]))
	[self batchDrawData:data];
	[drawData removeAllObjects];
	}
	}

From what I can tell, the non cgLayerEnabled codepath (aka the else path):

macvim/src/MacVim/MMCoreTextView.m

Lines 642 to 649 in 27bdb64

	} else {
	id data;
	NSEnumerator *e = [drawData objectEnumerator];
	while ((data = [e nextObject]))
	[self batchDrawData:data];
	[drawData removeAllObjects];
	}

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.

[CodeMonkeyKevin]

Any update on this.

[ychin]

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.