Sublime Forum

Buffer framerate tanks after GPU switch

#1

MacBook Pro 15", late 2016 touchbar model. macOS 10.13.1. Sublime build 3154

Whenever the GPU switches from integrated to discrete, sublime’s framerate collapses horribly. This holds until restarted, even if the machine reverts back to the integrated GPU. I can trigger this 100% reliably by launching any application which requires the discrete GPU (e.g. Photos is an easy one) after Sublime is already open. Scrolling and editor interactions go from buttery smooth to extremely jerky, with noticeable tearing and even sometimes lag (could be another bug; haven’t isolated that one yet). Framerate is 100% reliably smooth when remaining entirely on the integrated GPU.

1 Like
Dev Build 3154
#2

For better tracking, you could open a issue for this on the GitHub issue tracker:

  1. https://github.com/SublimeTextIssues/Core/issues
0 Likes
#3

does changing the value of "gpu_window_buffer" have any effect?

2 Likes
#4

This is some great details - thanks for the info. Does this only happen with the Adaptive theme, or with the Default theme also? Or are you running a third-party theme? Do you notice a CPU usage spike when the frame rate gets reduced?

I’ll see if I can reproduce with my machine, although I am running a late 2013 with 10.12. I doubt I’ll upgrade to 10.13 for this machine since I already had issues introduced with 10.12.

1 Like
#5

So I went to reproduce this today to see if I could get more details for you. It’s a bit different this time, which is interesting. Information discovered listed below…

  • Photos no longer requires the discrete GPU (as of 10.13). I had been reproducing with Slack (their video calling is currently bugged to require the discrete GPU), and had also been able to reproduce it with other applications which trigger the GPU swap (such as Gitter’s buggy Electron version and VMware Fusion 10 with hardware accelerated video). These still reproduce it.
  • It appears that the framerate decay no longer persists beyond the swap back to integrated. I started Sublime fresh, observed buttery scrolling framerate with about 12-15 buffers open, all Scala mode. Opened VMware and launched a suspended vm (which triggers the discrete GPU). Went back to sublime, observed severely decayed framerate (more on this in a bit). Suspended the VM and shut down VMware (which resumed integrated GPU). Framerate was back. I’ll play around with reproducing using Slack later, since that was a bit more severe.
    • Also note: I tested the framerate after resuming the VM but before giving it focus. This is significant because the hypervisor activates when the VM resumes, but the discrete GPU doesn’t activate until it gets focus, so we can rule out the overhead of VMware itself causing any sort of performance hit.
    • Theory on the “no longer persisting after swap back” result… My testing was all very quick: reproduce bug, then shut things down and go back to integrated GPU, all within less than a minute. Previous natural reproductions had the discrete GPU active for much longer (often upwards of an hour). Perhaps this makes a difference?
  • It’s possible that the framerate decay is proportional to the number of buffers open. I actually wasn’t even sure I was seeing it at first, with only a dozen up. Normally I have upwards of 100 open files, and the decay is usually severe (i.e. eyeballing it, feels like around 10-15 FPS at the most).
  • I’m using the Adaptive theme. No modifications. Sidebar and status bar hidden. Git Gutter is the only other thing affecting visuals. Master version of the Scala mode. Custom color scheme based on Material Dark (I added quite a few more-specific scopes, and corrected the handling of some of the existing ones; nothing too crazy).
  • Same symptoms with the Default theme, using the same reproducer.
  • Very yes on the CPU spike. I have Sublime running in fullscreen mode, but reproducing the issue, swapping to Sublime, scrolling back and forth a bit, then swapping to Activity Monitor showed Sublime at 15% CPU. Doing the same thing when the framerate is stable shows 0% CPU. Theory: Could Sublime’s hardware acceleration be failing to swap over to the newly-active GPU and thus pushing all rendering onto the CPU?

I think that’s all the relevant stuff. Let me know if you need more details!

3 Likes
#6

Reconfirmed that the buffer framerate drop does persist when the discrete GPU has been in use for a while (I tested with about 30 minutes). So my guess is that sublime is able to recover when the integrated GPU comes back quickly, but something gets GC’d at some timeout greater than a minute, at which point sublime will just never be able to get back to proper rendering.

1 Like
#7

Thanks to your work here I was finally able to reproduce the issue. Thank you very much!

3 Likes
#8

To be clear here for future googlers: Set the gpu_window_buffer setting to true to fix this.

0 Likes