Scrolling / moving cursor is slow when GPU is under high load on macOS

[juliangarnier]

Description of the bug

Scrolling and moving cursor is janky on ST4 when the GPU is under high load.
Here is a comparison between a fresh ST 3211 build and ST 4164 in safe mode:

st4-slow.mp4

I can confirm the problem has been present since the first public build of ST4, scrolling and moving cursor always felt less reactive in general compared to ST3.

Here's the fps log in the console:

fps: 7.5 average: 1ms
fps: 20.6 average: 0ms
fps: 36.5 average: 1ms
fps: 65.7 average: 1ms
fps: 66.4 average: 1ms
fps: 68.7 average: 1ms
fps: 43.6 average: 1ms
fps: 74.9 average: 1ms
fps: 63.6 average: 1ms
fps: 73.8 average: 1ms
fps: 66.2 average: 1ms
fps: 65.6 average: 1ms
fps: 66.6 average: 1ms
fps: 68.2 average: 1ms
fps: 4.8 average: 0ms
fps: 0.4 average: 1ms

Possibly related to #6140?

Steps to reproduce

1. Start ST4 in safe mode.
2. Open a file big enough to be able to scroll through it.
3. Test scrolling and using the arrows down and up (performance should be fine).
4. Open a web browser and open this 3D demo link https://threejs.org/examples/?q=instanc#webgl_instancing_performance (crank up the count value to make the problem more obvious).
5. Go back to ST4 and scroll / navigate with the arrow keys again.

Expected behavior

Scrolling performance should be identical or at least close to before opening the 3D demo and on par with ST3.

Actual behavior

Scrolling through the document is slow while running the 3D scene in the background.
Navigating with the arrow keys is even slower (looks like 20/30 fps on my machine).

Sublime Text build number

4164

Operating system & version

macOS 13.4.1

(Linux) Desktop environment and/or window manager

No response

Additional information

MacBook Pro

CPU: 2,3 GHz Quad-Core Intel Core i7
GPU: Intel Iris Plus Graphics 1536 MB
RAM: 32 GB 3733 MHz LPDDR4X

The problem happens when using either only the built-in retina display or using an external 1080p monitor.

OpenGL context information

OpenGL Context Information:
  GL API Version: 4.1 INTEL-20.6.1
  GLSL Version: 4.10
  Vendor: Intel Inc.
  Renderer: Intel(R) Iris(TM) Plus Graphics OpenGL Engine

[BenjaminSchaaf]

I'm able to reproduce this, but it happens not just for ST but any other app that uses the GPU for rendering including Finder, Safari itself and the compositor (Three-finger swipe up lags). As such I don't think this has anything to do with Sublime Text, but rather macOS and safari letting a web page use up all GPU system resources (especially while the web page isn't in focus).

Trying ST3 I'm seeing the same behavior there, though perhaps to a lesser degree.

[juliangarnier]

Thanks for looking into this.

Trying ST3 I'm seeing the same behavior there, though perhaps to a lesser degree.

On my machine, the difference in performance between ST3 and ST4 is huge.

Here are two videos comparing the scroll performance while moving the cursor using the down arrow key on a fresh install of both ST3 and ST4 with ST4 running in safe mode.
I shot the videos with my phone, so it doesn't alter the framerate of the recording.
Note that on my machine, the KeyRepeat delay is set to "1" (or 15ms). This setting allows me to move the cursor without any visual delay, which feels great in ST3.

ST3:

IMG_5342.mp4

ST4:

IMG_5343.mp4

You can clearly see that while I move the cursor in ST4, the framerate of both the editor and the animation on the right suffers.
ST3 has almost no visual impact on both the editor and the animation.

[juliangarnier]

And for comparaison, here's a recording of VSCode :

IMG_5344.mp4

The cursor animation is not as smooth as ST3, but it's still way better than ST4.

Also this is VSCode running mostly out of the box with the LSP activated.

If I run my "normal" ST4 setup with LSP on, the framerate drops even further, rendering the editor barely usable.
This could be due to the ST4 LSP plugin being slower than ST3, so I shouldn't focus too much on that for now, but I think it's worth mentioning / showing how bad it can get:

IMG_5345.mp4

ST3 runs fine with LSP on:

IMG_5348.mp4

[deathaxe]

ST 4165 with the 3D scene running on Win11 behaves nearly the same way as VS Code in your screenshots, but with 3D scene's FPS dropping significantly. Caret moves with inconsistent speed and some pauses in between. But that's happening without regards to current CPU load - even if 3D scene is not running.

I know main root cause being discussed here is Mac's compositor, but ...

did you make a benchmark with ST4 and LSP disabled? Just asking, because syntax definitions have also changed significantly between ST3 and 4, which may (or may not) be another possible factor for differences. Especially JavaScript makes significant use of "branches". I also noticed lags when moving caret up and down in Python, with some larger branches being involved. To reproduce, just checkout https://github.com/wbond/package_control/blob/four-point-oh/package_control/tests/test_providers.py and move caret over larger @data decorators.

[juliangarnier]

did you make a benchmark with ST4 and LSP disabled?

Yes, these two videos show fresh ST3 / ST4 installs without any plugins running.

Thanks for looking into this.

Trying ST3 I'm seeing the same behavior there, though perhaps to a lesser degree.

On my machine, the difference in performance between ST3 and ST4 is huge.

Here are two videos comparing the scroll performance while moving the cursor using the down arrow key on a fresh install of both ST3 and ST4 with ST4 running in safe mode. I shot the videos with my phone, so it doesn't alter the framerate of the recording. Note that on my machine, the KeyRepeat delay is set to "1" (or 15ms). This setting allows me to move the cursor without any visual delay, which feels great in ST3.

ST3:

IMG_5342.mp4

ST4:

IMG_5343.mp4

You can clearly see that while I move the cursor in ST4, the framerate of both the editor and the animation on the right suffers. ST3 has almost no visual impact on both the editor and the animation.

[juliangarnier]

Caret moves with inconsistent speed and some pauses in between. But that's happening without regards to current CPU load - even if 3D scene is not running.

@deathaxe, does this mean ST4 never has a stable framerate while scrolling or moving the cursor around on your machine?
Have you encountered the same issues on ST3?

[BenjaminSchaaf]

did you make a benchmark with ST4 and LSP disabled? Just asking, because syntax definitions have also changed significantly between ST3 and 4, which may (or may not) be another possible factor for differences. Especially JavaScript makes significant use of "branches". I also noticed lags when moving caret up and down in Python, with some larger branches being involved.

Note that branches aren't evaluated when scrolling unless there's a "discontinuity". You'd need to make changes to the file that cause the rest of it to be highlighted differently. Just loading a file fully highlights it from start to finish. If you're seeing this in a freshly loaded file then it can't be related to syntax highlighting.

[BenjaminSchaaf]

I can't reproduce the different behavior you're seeing between ST3 and ST4:

macos_intel_performance.mp4

Note this is on a 2015 macbook air and hardware acceleration disabled. With hardware acceleration enabled the lag is slightly worse and is noticeable earlier than it is using ST3, but that would be expected given that it uses the GPU for rendering.

[juliangarnier]

Note this is on a 2015 macbook air and hardware acceleration disabled. With hardware acceleration enabled the lag is slightly worse and is noticeable earlier than it is using ST3, but that would be expected given that it uses the GPU for rendering.

I think this is a really important difference to take into account here.

Because both my ST versions are hardware accelerated.
If I disable the hardware acceleration on ST4, the performance is worse, but the same thing happens if I set "gpu_window_buffer": false on ST3. In that case, both versions perform equally poorly.

Also, in your video, I see that you set the 3D demo count parameter to 10000, and I can see that the framerate of the animation plunges to around 17 fps.
That means your GPU is literally overwhelmed at that point, and I wouldn't expect any apps to run smoothly on top of that.

On my machine with a more beefy GPU, the count parameter is set to 7000, and the animation runs at a smooth 60 fps before starting to scroll. And you can see that ST3 has almost no impact on the 3D demo, where ST4 makes its framerate drop significantly.

So to recap in order to properly replicate my issue:

• Both ST3 and ST4 must have hardware acceleration on.
• For the 3D demo, ensure that the framerate stays around 60 fps before scrolling to more accurately mesure the impact difference on the GPU between ST3 and ST4

[BenjaminSchaaf]

Because both my ST versions are hardware accelerated.
If I disable the hardware acceleration on ST4, the performance is worse, but the same thing happens if I set "gpu_window_buffer": false on ST3. In that case, both versions perform equally poorly.

Note that even with "gpu_window_buffer": true ST3 renders using the CPU. The GPU is only used for copying the render to the window. In ST4 with hardware acceleration the actual rendering itself is done on the GPU and thus necessarily uses more GPU resources.

[juliangarnier]

Note that even with "gpu_window_buffer": true ST3 renders using the CPU. The GPU is only used for copying the render to the window. In ST4 with hardware acceleration the actual rendering itself is done on the GPU and thus necessarily uses more GPU resources.

Ha! OK, so yeah, I guess it makes sense then.
Somehow ST3 with its hybrid approach was hitting a sweet spot for me in terms of performance.
Would it be possible to re-expose the "gpu_window_buffer" parameter in ST4 that could be used with "hardware_acceleration": false to get the same rendering pipeline as in ST3?

[deathaxe]

does this mean ST4 never has a stable framerate while scrolling or moving the cursor around on your machine?

Console log displays constant 33fps and 2-3ms rendering time, while movig caret downwards.

It's just the scrolling speed, which varies or feels like lagging every here and then.

Note that branches aren't evaluated when scrolling unless there's a "discontinuity"

This is also what I have in mind. It just was a subjective impression lags being more noticible in such ranges of code. Moving caret also results in varying scroll speeds with opengl enabled if ST is started and the file just being opened without modifying it. I don't see such effects with "software-rendering", which is what I use most of the time. So that's not a real pain point for me.

[BenjaminSchaaf]

Would it be possible to re-expose the "gpu_window_buffer" parameter in ST4 that could be used with "hardware_acceleration": false to get the same rendering pipeline as in ST3?

The old rendering pipeline using the gpu buffer is not something we can easily bring back and I don't plan on ever doing so. In light of that I don't think it makes sense to keep this issue open.