Neovide is laggy when certain fonts are used (like Cascadia Code)

[Freemason-12]

Describe the bug When I use Cascadia Code as a default font in my AstroNvim config it starts to lag when scrolling down to the unvisited part of the code or text, if that part was scrolled, going back up is smooth

To Reproduce Steps to reproduce the behavior:

1. Set Font to Cascadia Code
2. Open some long code with some TreeSitter parser, linter/LSP installed for this language
3. Scroll down
4. See lag

Expected behavior everything smooth

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [KDE Neon 5.26]
• Neovide Version [e.g. 0.10.3]
• Neovim Version [e.g. 0.8.1]

Please run neovide --log and paste the contents of the .log file created in the current directory here:

Additional context Add any other context about the problem here.

[shivamchandra75]

Hey , @Freemason-12 I am having laggy cursor animations and laggy scroll, with the same environment that you mentioned to Reproduce. But i found that the jittery animations are noticeable ONLY WHEN LINTER IS ENABLED. I also tried with JetBrainsMono Nerd Font and still laggy animations with linter enabled not so noticeable with linter disabled. Note: linter disabled the lag is very little but still there...

Video showing lag

https://github.com/neovide/neovide/assets/83809266/8360fa5b-2a65-413d-bbff-925b833df3c6

[fredizzimo]

I think that this might have fixed the original issue

• https://github.com/neovide/neovide/pull/2354

The problem @shivamchandra75 has is different, and I think it's caused by some plugins and not by Neovide, so there's nothing we can do about that.

Would it be possible for someone that experienced the lag with Cascadia Code to confirm that it's fixed or not on main (0.12.2 does not include the fix)?

[fredizzimo]

If that's not the case, could you attach a tracy log following the instructions here https://neovide.dev/troubleshooting.html#performance-profiling?

[rp1231]

I'm using Caskaydia Cove Nerd Font mono and I'm getting a laggy cursor. Especially when switching from normal mode to the command bar by pressing : Here is a video showing that, especially towards the end of the animation.

https://github.com/neovide/neovide/assets/47380919/bcf09c7b-68c2-4238-87cd-18ab51068366

[fredizzimo]

@rp1231, are you able to build main from source? There was a bug with loading Cascadia Code that was fixed here:

• https://github.com/neovide/neovide/pull/2354

If that does not help I guess we need the profiling information according to these instructions: https://neovide.dev/troubleshooting.html#performance-profiling?

It's ok, if you are not, able to do it, but then we need someone else that can repeat the bug to reproduce it.

[rp1231]

@fredizzimo I was able to build main from source but was still encountering the same issue. I've attached the tracy file below neovide.zip

[fredizzimo]

@rp1231 I might look at this a bit more later, but my first impression is that it does not have anything to do with the fonts in this case, but instead caused by the randomly missed vsyncs when using opengl on Windows.

That will be fixed by

• https://github.com/neovide/neovide/pull/2215

[rp1231]

You're right, I just removed my font config and still encountered the problem.

[rp1231]

@fredizzimo I tried out the d3d branch you mentioned. But I'm still encountering the same cursor lag when switching from normal mode to the command bar as shown in the video. Also it's not really the cursor thats lagging, but the animation that becomes choppy towards the end. Almost as if not enough inbetween frames are being drawn for that long streak.

[fredizzimo]

@rp1231, well, in the profiler I saw one frame that was over 100 ms, because the vsync detection did not trigger, and another frame that took too long to render for no apparent reason. Both of which should be fixed by the d3d frame.

Can you take another profiling log from that branch?

And to make it easier for me to see what's going on, wait around 10 seconds between before pressing :, then around 5 seconds before pressing esc, and then 10 seconds again before : and so on. Repeat that a few times, so that the lag is visible. Then you can quit, preferably wait 20 seconds before quitting.

If the lag does not happen every time, you can tell how many times you pressed : before it happened.

I can then count the delays to know exactly what's happening.

[rp1231]

@fredizzimo Also before taking the profiling log, I just want to make sure I did it the right way. Because the tracy-capture command mentioned in the documentation did not work for me. What I did was start the tracy gui and clicked on connect to capture the log. Hope that is also a valid method.

[fredizzimo]

@rp1231, yes, that's also a valid method. I'm not sure why the command did not work though, but maybe there's some difference in the windows version.

[rp1231]

@fredizzimo Here's the trace from the d3d pull request version neovide_d3d.zip

[fredizzimo]

Thanks. There has to be something going on, on the GPU side, every animation looks roughly like this

Where the only information we have, is that it's waiting for vblank/vsync for around 150ms. The rest of the frames are a stable 60 FPS.

Which graphics card do you have, I can only see the CPU information in the trace?

The bad thing is that I'm not sure how to track this down further without using complicated tools, which furthermore takes big captures.

There's one thing you can try, but I'm not sure if it works properly, add --features gpu_profiling to the command. This will slow everything down, but the trace could still give useful information. At least if the GPU is busy or not.

[rp1231]

I'm on a lenovo legion 5 pro with an AMD Ryzen 7 6800H and an Nvidia 3070ti graphics card. The laptop has onboard graphics as well but I have turned that off and am completely running on discrete graphics card. I'll try out the command you mentioned.

[rp1231]

Here's the log with the gpu profiling command added: neovide_d3d_gpu.zip

[fredizzimo]

It looks as if something might be too heavy on the GPU side, which is strange, since your graphics card should definitely be good enough. Only the first frames are rendered in time and waits for the vsync on the GPU, then it starts to lag more. All time is spent in Skia, submit_surface without any further information.

But it could also be some kind of synchronization issue, because it renders for 10 frames, then waits for the same number of frames until it starts rendering again.

I will boot into Windows a bit later, maybe tomorrow, to check how it looks like on my system for comparison.

But if you have time, you could take another capture, with --profile profiling --features profiling --features gpu_profiling -- --no-fork --no-vsync --no-idle

And then inside neovide :let g:neovide_refresh_rate=9999, that should make the framerate unlimited and might show some issues.

[rp1231]

I did run the commands with a couple hundred browser tabs in the background.... Maybe that would explain the heavy usage..... I'll try out the new command with no program running in the background.

Edit: I tried out neovim without any program running in the background and still got the cursor problem.

[rp1231]

@fredizzimo Here's the tracy file with the options you mentioned. neovide_d3d_v2.zip

[fredizzimo]

The trace looks very strange. I guess I have to compare how it looks on my system to know what's going on.

But it might just be that the gpu profiling slows it down so much that it becomes useless. Maybe it would be good to have one with the same parameters and no gpu_trace as well, so I have all combinations when I start to compare.

[rp1231]

Here you go neovide_d3d_v3.zip

[fredizzimo]

Thanks. I still have no idea what's going on, but there's clearly something strange, you should be getting around 1000 FPS, I think, but it's not even hitting a stable 60.

But that might be a problem with my d3d branch, I'm not sure it can properly run without vsync. The standard master version with opengl should do that though.

[rp1231]

neovide_nogpu.zip Here's a log of the standard master version with --no-fork --no-vsync --no-idle and no gpu profiling.

[rp1231]

Also I'm on a 4k external monitor btw, maybe that makes a difference in the FPS?

[fredizzimo]

This is very weird, first it runs at around 1000FPS, with a few frames taking long around 3 ms, then it throttles to 60 FPS, and then to around 6FPS (150 ms) for a frame, and then back to 60 FPS. And it's blocking in wait_for_vsync which is just a sleep. I think this might have something to do with the timer resolution throttling https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessinformation. But I need to read up more on that.

The --no-idle behaviour also appears to be slightly broken and I don't understand how it runs at 30 FPS, if you set :let g:neovide_refresh_rate=9999. But that might be another bug, and not related to the problem

[rp1231]

@fredizzimo I used neovide on my older, not as capable laptop, and strangely enough, it's snappy on that machine. The older laptops specs are an i7 processor and a nvidia 960m.

Also were you able to get any further insights on the problem? Thanks

[rp1231]

@fredizzimo I found out the cause of the problem. It wasn't anything to do with neovide but a feature called smart fn lock I had enabled on the lenovo legion toolkit software. It works flawlessly now.