Skip to content

Scroll Performance on Retina Screens #499

Closed

Description

@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

Activity

  1. jordwalke commented on May 16, 2017

    @jordwalke
    Contributor

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

  2. amadeus commented on May 16, 2017

    @amadeus
    Author

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

  3. jordwalke commented on May 16, 2017

    @jordwalke
    Contributor

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

  4. amadeus commented on May 16, 2017

    @amadeus
    Author

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

  5. amadeus commented on May 16, 2017

    @amadeus
    Author

    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.

  6. amadeus commented on May 18, 2017

    @amadeus
    Author

    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

  7. amadeus commented on Aug 9, 2017

    @amadeus
    Author

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

  8. StaverDmitry commented on Nov 27, 2017

    @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

  9. amadeus commented on Nov 27, 2017

    @amadeus
    Author

    I also want to add an additional video - of nearly the same experiment but using a non retina, or a 1x monitor:

    1x example video

    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.

  10. amadeus commented on Apr 30, 2018

    @amadeus
    Author

    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:

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

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

    } 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.

  11. CodeMonkeyKevin commented on Jun 30, 2018

    @CodeMonkeyKevin

    Any update on this.

  12. ychin commented on Dec 20, 2018

    @ychin
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions