search

sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
803 stars 39 forks source link

Severe scroll lag and high CPU usage #4446

Open sweettyler opened 3 years ago

sweettyler commented 3 years ago

Description

As title.

Steps to reproduce

  1. Start Sublime Text with option "--safe-mode".
  2. Load a file (any type, C/C++ or Python) containing about normal lines.
  3. put cursor in the opened sublime text window and use mouse to scroll, and at the same time check the CPU usage with Linux command "top -d 0.5 | grep sublime".

Expected behavior

Acceptable scrolling smoothness.

Actual behavior

Sublime text is almost unusable, possibly caused by unnecessary display redraws or redraw requests. BTW, VScode did use more RAM but the performance was MUCH better (sometimes VScode did use about 20% of CPU but I didn't feel any lag)! The following is the CPU usage while I was scrolling:

16931 pzha 20 0 1297628 175892 128704 R 98.1 0.2 0:00.51 sublime_text
16931 pzha 20 0 1376160 264876 209716 S 40.4 0.2 0:00.72 sublime_text
16931 pzha 20 0 1507996 410340 355024 S 37.3 0.4 0:00.91 sublime_text
16931 pzha 20 0 1507996 410340 355024 S 0.0 0.4 0:00.91 sublime_text
16931 pzha 20 0 1507996 410340 355024 S 0.0 0.4 0:00.91 sublime_text
16931 pzha 20 0 1244360 168936 113648 R 7.8 0.1 0:00.95 sublime_text
16931 pzha 20 0 1376200 216980 161540 S 13.5 0.2 0:01.02 sublime_text
16931 pzha 20 0 1376200 216980 161540 S 0.0 0.2 0:01.02 sublime_text
16931 pzha 20 0 1245128 88888 33428 S 0.0 0.1 0:01.02 sublime_text
16931 pzha 20 0 1245128 88888 33428 S 0.0 0.1 0:01.02 sublime_text
16931 pzha 20 0 1245128 104724 49264 S 3.8 0.1 0:01.04 sublime_text
16931 pzha 20 0 1245128 104948 49484 S 2.0 0.1 0:01.05 sublime_text
16931 pzha 20 0 1376200 300832 244764 S 38.5 0.3 0:01.25 sublime_text
16931 pzha 20 0 1376200 300832 244764 S 0.0 0.3 0:01.25 sublime_text
16931 pzha 20 0 1376200 300832 244764 S 0.0 0.3 0:01.25 sublime_text
16931 pzha 20 0 1376200 300832 244764 S 0.0 0.3 0:01.25 sublime_text
16931 pzha 20 0 1376200 300832 244764 S 0.0 0.3 0:01.25 sublime_text
16931 pzha 20 0 1376200 252876 196220 S 25.5 0.2 0:01.38 sublime_text
16931 pzha 20 0 1376200 333924 277268 S 21.2 0.3 0:01.49 sublime_text
16931 pzha 20 0 1639880 525852 468876 R 37.3 0.5 0:01.68 sublime_text
16931 pzha 20 0 1903560 729924 672628 R 42.3 0.6 0:01.90 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 30.8 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887268 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887276 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887276 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887276 829812 S 0.0 0.8 0:02.06 sublime_text
16931 pzha 20 0 2035400 887276 829812 S 0.0 0.8 0:02.06 sublime_text

Environment

BenjaminSchaaf commented 3 years ago

Duplicate of #4223

sweettyler commented 3 years ago

@BenjaminSchaaf I don't have a GPU so I am not sure if this is a duplicate of #4223.

BenjaminSchaaf commented 3 years ago

4223 is not just about GPU rendering.

zalsaeed commented 3 years ago

Same issue here. I will add whenever you save (even with smaller files - in kb), there will be a ~1 second lag before you gain control back. For me the file type doesn't have an effect. It can be any file.

Env:

deathaxe commented 3 years ago

As ST claims to save files asynchronously (which should not cause UI to block) it may probably be a plugin which performs some action on synchronous on_pre_save event, which causes UI to block if execution takes too long.

sweettyler commented 3 years ago

In my case it has nothing to do with plugins and saving files (no saving at all). It is more likely caused by more than necessary redraw or refresh of display.

BenjaminSchaaf commented 3 years ago

@zalsaeed That's most likely caused by a plugin - try safe mode. It's also unrelated to this issue, as this issue is about scrolling normally not about a hang in save.

zalsaeed commented 3 years ago

@BenjaminSchaaf Not sure about safe mode. And you are right the issue is not about saving, but I thought I should bring it up as it happened after the new release and it is about lagging. Anyway, it still the case that I too have a scrolling lag. And again that is regardless of the file type.

BenjaminSchaaf commented 3 years ago

@zalsaeed safe mode: https://www.sublimetext.com/docs/safe_mode.html

sweettyler commented 3 years ago

I double checked what I reported with the latest build 4109. I feel that v4109 is a bit better than v4107 (just a feeling, I might be wrong).

If I run subl in safe mode ("subl --safe-mode") I feel the scrolling is even worse than in normal mode (I load the same file, ~200 lines Python code, and resize both windows to the same size). Is this possibly caused by my setting "ui_scale: 2.0" disabled in safe mode and thus subl has more lines to display in this case?

BenjaminSchaaf commented 3 years ago

@sweettyler What screen resolution are you using (how large are the windows)? To clarify: was it just as slow in ST3 or is this a regression?

sweettyler commented 3 years ago

@BenjaminSchaaf My screen resolution is 3840x2160 (4K), this is why I set ui_scale to 2.0. Will try with ST3 tomorrow and let you know the result.

BenjaminSchaaf commented 3 years ago

At those resolutions the software rendering used by default will struggle to keep up. I suggest using "hardware_acceleration": "opengl".

sweettyler commented 3 years ago

@BenjaminSchaaf I tried to use ST3 for the same test this morning and found no noticeable difference, so it is not a regression introduced in ST4. However, as I mentioned earlier, I use VScode a lot, and what I see is with the same hardware, same OS, same file, and same window size, VScode code performs much better in terms of scrolling. I do understand VScode and ST are different, but shouldn't I expect ST do a better job (or at least as good as VScode)? BTW, I don't have GPU in my system.

BenjaminSchaaf commented 3 years ago

You're outputting to a 4k display and presumably get reasonable performance in your browser and desktop environment, I guarantee that you have a GPU. Browsers like chrome use the GPU by default for drawing and thus easily scale to higher resolutions, hence why VSCode doesn't have a problem doing that. ST4 introduces the same feature.

sweettyler commented 3 years ago

Yeah, you are right! Just checked with lspci and it shows I do have a GPU card: 0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller]) ... 0001:00:00.0 VGA compatible controller: NVIDIA Corporation GM204GL [Tesla M60] (rev a1) (prog-if 00 [VGA controller]) ... However, when I add "hardware_acceleration": "opengl" to my settings, and after relaunching ST4, I got the following message:

Failed to initialize OpenGL rendering: 0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.10, 1.20, 1.00 ES, and 3.00 ES

The code was displayed correctly but the menu on top was missing and that area left blank, and the scrolling experience improved a lot.

BenjaminSchaaf commented 3 years ago

Unfortunately we currently have a high opengl requirement, so you won't be able to use it. Essentially this issue can be changed to "Support OpenGL ES 3.0 for hardware acceleration".

sweettyler commented 2 years ago

I think I know why now: in ST the smooth scrolling is enabled by default however in VSCode it is disabled by default. If I disable it in ST then the scrolling performance is about the same as that of VSCode.