After VS Code with it’s perfect and smooth (like web page) scrolling, I can’t normally use Sublime with it’s scorlling on windows. Sublime scrolling on MacOS is perfect, but sublime scrolling on Windows very odd. The same problem has WebStorm on Windows. Can someone explain:
I’m using a mouse with free-scroll wheel on Linux and scrolling can be a bit choppy indeed, especially when the animation slows down right before going to a full stop. This has always been the case with Sublime, not only with the latest release. I was expecting to see better performance with the hardware rendering option, but it looked the same even after restart.
Here is the output of glxinfo -B on my end:
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT3) (0x3ea5)
Version: 19.2.8
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT3)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.8
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.0 Mesa 19.2.8
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
It’s a pretty decent integrated GPU.
Did you enable hardware rendering and restart Sublime? Does the GL information it displays in it’s console agree with what you see here?
Yes:
OpenGL Context Information:
GL API Version: 4.5 (Core Profile) Mesa 19.2.8
GLSL Version: 4.50
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT3)
But again, I don’t see any difference. Probably a better explanation on what to expect will be helpful too. Not in the main documentation, but probably a link to a YouTube video or a page with more details about it. I know that feature was implemented mainly to address performance issues on larger displays, but am I supposed to notice any difference on a regular 1080p display?
but am I supposed to notice any difference on a regular 1080p display?
Not with a normal desktop processor, no. My guess is there’s something else going on. One of the features that came along with OpenGL rendering was vsync on windows, which may be what’s causing the issues.
I’m on Linux btw. Also changing the refresh rate of my monitor down to 60Hz increases the lag. On 144Hz seems much better, but still not ideal. Software rendering yields better results than the hardware one on my end.
Not entirely sure what a normal desktop processor have to refer to either. It’s the same CPU found in current gen Mac books (not A1). It is the Iris Plus one, same as the one shown in the docs, it’s just that it doesn’t use the same code name on Linux for some reason.
I’m on Linux btw. Also changing the refresh rate of my monitor down to 60Hz increases the lag. On 144Hz seems much better, but still not ideal. Software rendering yields better results than the hardware one on my end.
Linux has had a similar vsync change.
Can you enable fps logging: sublime.log_fps(True) to confirm whether the actual frames are rendered quickly enough or if it’s a different problem?
Yes, it seems that the hardware rendering is capped at 60 fps, that’s why I’m seeing better results with the software one.
with software rendering enabled:
ps: 102.6 average: 1ms
fps: 57.4 average: 1ms
fps: 15.9 average: 0ms
fps: 142.8 average: 1ms
fps: 115.9 average: 1ms
fps: 141.9 average: 1ms
fps: 89.8 average: 1ms
fps: 140 average: 1ms
fps: 84.9 average: 1ms
fps: 144.1 average: 2ms - when scrolling around
fps: 144.9 average: 1ms
fps: 138.9 average: 2ms
fps: 144.8 average: 1ms
fps: 144 average: 1ms
fps: 131.9 average: 1ms
fps: 87.4 average: 2ms
fps: 13.4 average: 0ms
with hardware rendering enabled:
fps: 14.4 average: 0ms
fps: 24.5 average: 3ms
fps: 14.4 average: 1ms
fps: 34.7 average: 4ms
fps: 14.5 average: 1ms
fps: 61.1 average: 1ms
fps: 54.6 average: 1ms
fps: 61 average: 1ms
fps: 56.5 average: 1ms
fps: 60.9 average: 2ms - when scrolling around
fps: 61 average: 3ms
fps: 61 average: 2ms
fps: 61 average: 2ms
fps: 58.3 average: 1ms
fps: 53.8 average: 1ms
fps: 61.1 average: 2ms
fps: 60.7 average: 2ms
fps: 44.3 average: 4ms
fps: 61 average: 1ms
fps: 20.2 average: 2ms
fps: 21.4 average: 3ms
Just to clarify I’m using the default scroll speed of 1.0 and the lag occurs only when the scroll animation changes speed. It’s noticeably laggy when it deaccelerates especially.
I’d like to join the conversion to report my observations.
Recently, after latest ST4 4109 (dev channel) update I also noticed scrolling the editor is not smooth and a little jagged (with HWA, not tested with SW yet). After toggling a few suspected extensions as well as searched the web for some reported scroll jank causes, I managed to improve the jagged scroll with these changes:
Edited: I forgot to report my system: It’s a MacBook Pro 2019 with macOS Big Sur 11.4 installed.
GitGutter’s line annotation is added/updated only if caret is moved to another line and removed as soon as caret moves horizontally. It is not updated while scrolling. Thus degrated scrolling performance may be related with rendering performance of line annotations only.
I noticed scrolling is super janky (as in completely unusable) lately with large selections. I’m on an M1 Air w/ latest build, "hardware_acceleration": "opengl" set, using an external HiDPI monitor, though the issue happens with just the native screen also.
If you select an area larger than the screen size it triggers the issue, and it gets much worse the larger the selection, to the point of making the app unresponsive on a 400k file.
I just realized after reading the comment above that turning off the minimap fixes performance immediately, so it appears to be from minimap rendering.
Very bad scrolling on Win10 (21H1 19043.1151), logger shows high frame rate, but it looks like 60 Hz anyway on 240 Hz display 
It’s easy to compare scrolling here (web browser, forum) and sublime’s file or console (ctrl+shift+p). I can see text traces that really looks like 60 Hz rendering or even low. Hope it’ll be fixed further because it’s very annoying…
Sublime Text, stable channel, Build 4113
Btw the same for internal sublime file explorer
Unfortunately, I’m experiencing the very same issue on a 16" MacBook Pro. It is funny that this does not happen on my iMac, which also has a retina screen.
Both are running macOS Big Sur 11.4 (20F71) with Sublime 4113, Stable Channel. I don’t think installed packages are interfering, since having them installed or not does not affect the aforementioned behaviour, but for completeness sake, those are the packages currently installed:
Logging FPS shows lots of complaints, along with a very low FPS (hardware_acceleration: none)
fps: 11.5 average: 4.87312e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31614e+08ms
Frame time exceeded 60hz: 5.31615e+08ms
Frame time exceeded 60hz: 5.31615e+08ms
Frame time exceeded 60hz: 5.31615e+08ms
Changing hardware_acceleration to opengl improves it, consistently yielding a higher FPS when scrolling:
fps: 70.6 average: 1ms
fps: 59.4 average: 1ms
fps: 23.8 average: 0ms
fps: 23.8 average: 0ms
fps: 23.9 average: 0ms
fps: 35.8 average: 1ms
fps: 68.2 average: 2ms -- began scrolling
fps: 82.2 average: 2ms
fps: 87.7 average: 3ms
fps: 61.7 average: 2ms
fps: 85.8 average: 2ms
fps: 77.4 average: 2ms
fps: 23.9 average: 0ms -- finished scrolling
fps: 23.9 average: 0ms
fps: 23.7 average: 0ms
fps: 22.8 average: 0ms
fps: 24.5 average: 0ms
fps: 33.7 average: 1ms
fps: 10.2 average: 1ms
fps: 15.5 average: 1ms
fps: 14 average: 1ms
Edit: Restarting Sublime Text seems to solve the issue for some time, until it needs restarting again. 
I just updated to build 4121 and this is a great one, I displayed the FPS and I get consistent 144 fps now where I had more around 80 - 100 FPS before 
Came back to add that I still have the same problem on 4121.
Now running Monterey 12.0.1 (21A559)
Also found another post that may be related:
Edit: It seems running ST4 on Full-screen mode makes it worse. When running as a window (pretty much the same size of full-screen, minus the Dock and Menubar size), I’m able to get 60+fps
Can you provide another fps log from 4121? Note that with hw acceleration enabled, as it is by default, it didn’t look like you were getting any slowdowns before?
On my end on Linux the default rendering still seems a bit better 4121. Also the hardware one is still capped on 60 fps. So sublime.log_fps(True) still yields the same output for both the hardware and the default one, around 2-3ms 60fps and 2-3ms for 144fps respectively. Though it seems that the scrolling got a bit smoother visually.
It still have some stuttering when it deaccelerates. I don’t know if you test/optimize for freescroll mouse. Last time I was testing with Logitech MX Anywhere 2, but since then I got the Logitech MX Anywhere 3 which have an even higher sensitivity on the scroll wheel. So I can scroll through thousands of lines of text with a single scroll movement, but this mode also makes the deaccelerate stuttering even more noticeable. Again my GPU is the Iris Plus 8th gen Intel, but on Ubuntu Linux, you can see it above in my previous comment.
@bschaaf I recorded a short video on my desktop at 144fps. The format is .mkv so you may need VLC player to view it on a Mac.
Notice how the animation stutters when it deaccelerates. The hardware (the scroll wheel) spins freely up until the end. So I’m thinking that the issue is in how the software interprets that. I’m using the default "scroll_speed": 1.0.
NOTE: not using hardware_acceleration as that is capped on 60fps
Free scroll wheels are still stepped in that a certain amount of rotation translates into individual scroll events. If the wheel is spinning slowly that means it will send a scroll event at a slower interval than it takes ST to animate the entire last scroll event, so you end up with “stutters”. The same should be happening for any other application.
Additionally I can’t reproduce high-refresh rate not working using hardware acceleration:
