High refresh rate support

[szlend]

Check for existing issues

• Completed

Describe the feature

Scrolling through text in Zed feels choppier compared to Visual Studio Code on a high refresh rate display (MacBook Pro M1). It would be great if Zed supported rendering at high (or variable) refresh rates.

I'm not really sure how to verify if this is the case but is rendering capped at 60 fps right now?

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[as-cii]

Zed should adapt to the refresh rate of the screen it is being displayed on, so I think something weird is happening here. It would be great if you could enable the Metal Performance HUD:

/bin/launchctl setenv MTL_HUD_ENABLED 1

And then restart Zed. Something like this should appear on the top-right corner:

It would also be really helpful if you could capture a CPU Profile (via Instruments.app) of the zed process while you scroll around. Thank you!

[oliver-kriska]

Hello, I feel I have same issue. I recorded Metal Performance HUD:

CleanShot.2024-01-25.at.16.33.39.mp4

but I was not able to run CPU Profile, it crash every time when I select CPU Profiler in Instruments.app.

[szlend]

I opened Zed with MTL_HUD_ENABLED=1. I then kept scrolling to the bottom of the page, which took a few seconds as it was a large document. After the initial ramp up, the FPS (while scrolling) settled, averaging around 70fps.

I'll see if I can get Instruments.app running to get a CPU profile. I need to set up Xcode first though.

It does seem like variable refresh rate works though, so maybe worth relabeling this as a bug.

[szlend]

Here's a trace of me scrolling in Zed: zed-scrolling.trace.zip

FWIW, I also opened devtools and did some profiling in vscode. I can confirm that vscode scrolls at a consistent 120fps (~8.3ms per frame).

[mrnugget]

Hey @szlend and @oliver-kriska! Thanks for reporting. I've also seen some interesting FPS "problems" in past few days but I can't really track them down.

Me and @as-cii looked at your trace (thanks!) but nothing really stood out. We also couldn't reproduce it:

• I opened https://raw.githubusercontent.com/microsoft/TypeScript/main/src/compiler/types.ts in Zed and VS Code on my M3 Max display and scrolled with the MacBook touchpad as far as I could. I reached the same FPS numbers in both: ~110-120 depending on scroll speed.

Can you give us some more data points? All of the following might have an influence:

• Zed configuration: buffer font-family? UI font-family? Font-sizes? Line-height? Ligatures enabled or not?
• File you're scrolling through: what file? How long is file? Do you use a language server? What's the configuration (inlay hints, diagnostics, hints) you use there? Lots of errors/diagnostics to show?
• Display: what's the resolution and refresh rate? Do you have an external display connected too?
• How do you scroll? Keyboard/trackpad/mouse wheel? Does it show up with another mouse? Do you use consistent as-fast-as-possible scrolling or do you use the "momentum" thing of the touchpad?

Maybe we can also turn this around: can you open the types.ts file and see how fast you can scroll in that one?

Also, I know this is asking too much, but if you're in the mood: a phone recording of the Zed on a display being scrolled would be ideal, becaues that way it's easy to see how fast the scroll is (because it's hard to capture on a screenrecording).

[szlend]

@mrnugget I think I might have figured out how to reproduce this. The scrolling is smooth as long as the editor is open in windowed mode. As soon as I fullscreen it (so it moves to another workspace) it stars lagging again.

With the Metal HUD I can see that it switches from Composited to Direct when going fullscreen.

Let me know if you're able to reproduce it this way. If not, I can give you more data points as requested, or we can hop on a call.

[mrnugget]

Okay, that's very interesting. From what I understand, Direct should be faster than Composited.

I still can't reproduce it, even in fullscreen mode.

[szlend]

• Zed configuration: Defaults. I disabled all customizations to test this.
• File you're scrolling through: types.ts
• Display: Just the MacBook Pro M1 display (Sonoma 14.2.1), 3456 × 2234 (scaled 1728 x 1117) @ 120hz
• How do you scroll? Macbook trackpad. Keep scrolling to the bottom without losing momentum. But it's the same effect if you just jiggle up and down repeatedly. Or if you use the mouse cursor to move the scrollbar. I don't think it's related to the input device.

[haze]

Another repro here:

Zed configuration

{
  "theme": "Summercamp",
  "telemetry": {
    "diagnostics": false,
    "metrics": false
  },
  "vim_mode": true,
  "ui_font_size": 16,
  "buffer_font_size": 16
}

File you're scrolling through
https://github.com/haze/rehype-tree-sitter/blob/main/src/lib.rs

Display
Default 2023 14" Display (3024x1964 @ 120Hz (as 1512x982) [Built-in])

How do you scroll
Same as @szlend; scrolling all the way to the top and bottoms of file, jiggling, etc.

[szlend]

When I'm scrolling in Direct mode the Metal HUD shows the min FPS exactly 60 and max FPS exactly 120. To me it seems like variable refresh rate doesn't work in Direct mode and it alternates between 120fps and 60fps vsync. But that's just a guess.

Edit: Actually, I think it's the same in Compositor mode but the framerate is more consistent for some reason. I think variable refresh rate simply doesn't work.

[rev4324]

File you're scrolling through:
types.ts

Display
240Hz 1440p monitor rendering in scaled 5K - Gigabyte M27Q X, hooked up via Type-C to my M1 Air

How do you scroll?
MacBook trackpad. I tried to scroll fast without losing inertia. Zed is definitely scrolling faster using the trackpad, it's just less smooth.

Zed config

``` { "project_panel": { "dock": "right" }, "vim_mode": true, "base_keymap": "VSCode", "show_copilot_suggestions": false, "theme": "Rosé Pine", "buffer_font_size": 15, "buffer_font_family": "Hack", "formatter": "prettier" } ```

I have a VFR 240Hz, 1440p monitor set as fake HiDPI (macOS is rendering in 5K and scaling down to 1440p), so I figured I compare VSCode (Insiders) scrolling with Zed's (I have stable channel version installed).

Here's a screen recording with FPS meters in both VSCode and Zed. It doesn't really show the difference, but in person the difference is pretty apparent.
https://github.com/zed-industries/zed/assets/69842744/83373266-527d-495d-8944-9b50a9787f2f

The faster I scroll the slower it gets on both editors, but Zed's "baseline", normal speed scrolling is ~70-100fps, while VSCode's is 200-240fps.

[mikayla-maki]

Hmmm, I wonder if that means the issue is in our editor somewhere, rather than in the framework 🤔, thanks for the research @rev4324

[mrnugget]

Hey all! Thanks for the recordings and data everyone. We're still debugging this.

The problem is that this is really hard to reliably reproduce. It's also hard to know which measurements are exact and which aren't. Example: Apple's Metal HUD seems like it has a life of its own and sometimes it shows the Hz of the external display on which it's displayed, sometimes it doesn't. VS Code's FPS meter constantly shows 120fps, even if nothing happens on screen.

I can say that I can get 120fps to show up on the MBP display when scrolling in Zed, BUT the Pre times that are on the Metal HUD (supposedly "time between presents" or "frame times" according to Apple) don't match what we log as frame times. See here:

on_mbp_display.mp4

The frame durations we log (when ZED_MEASUREMENTS=1 is set) are consistently <5ms, yet the Metal HUD shows Pre time as 18ms:

That's one interesting thing I want to investigate.

The other is that it's really hard to reliably reproduce any consistent frame rates: sometimes I get ~60FPS on this external display, sometimes ~80fps, sometimes on the MBP it hovers around 80fps, sometimes around 120fps.

---

The other thing worth mentioning here is: does this maybe have something to do with the scrolling itself and not the FPS? VS Code has a very high scroll speed. It's really easy to just flick on the touchpad and scroll down 400-500 lines, vs. the 250 you get in Zed. So maybe scrolling is involved too. Investigating.

---

If anyone wants to help investigate this further:

1. Can you try running Zed with ZED_MEASUREMENTS=1 and see what frame durations are reported and whether they match what's reported in the Metal HUD?
2. @as-cii and I have investigated a new approach for our main render loop, which is simplified and entirely based on macOS' display link. It could be faster (it feels faster but the HUD doesn't confirm, at least not consistently). So if you want to try this out, that'd be very interesting:

• Check out display-link branch
• Run cargo run --release
• Scroll your heart out, see if this feels different

[oliver-kriska]

I tried that branch and it feels same. And hud shows lower FPS, max about 80. Preview shows max about 110 FPS. Frame duration in console is about 5-9 and a few 4, not a lot. So it's a little slower, that's my basic feelings.

[mrnugget]

Just dropping more data in here. I took profiles/traces of Zed in Instruments.app, only on the MBP, no external display attached.

And, well: we do hit the 8ms pretty consistently. There are some blocking wait times, but as far as I understand everything that's going on that's because the main thread is blocked on events. So these blocks also coincide with me hitting the touch pad to scroll (I have to admit: I learned in the past few days that I'm pretty bad at consistently scrolling fast through a 10k line file a touch pad...)

[diocletiann]

I also had noticeable jitter on the 120hz MBP display a couple of days ago (gone today) and it reminded me of neovide/neovide#2102

[mrnugget]

I also had noticeable jitter on the 120hz MBP display a couple of days ago (gone today) and it reminded me of neovide/neovide#2102

Yup, that's what we have implemented in the display-link branch. I'll try to make progress on that today as much as possible.

[mrnugget]

Little end-of-day-update:

• Made progress on the display-link branch, removed the blocking call, made it redraw on window resize and window launch. So now it should work as before.
• I still can't really say that we don't support high-refresh, because I can get it to render at ~120fps with and without that branch.
• @ConradIrwin, @bennetbo and I then investigated the scrolling more and pushed a commit to the branch that does the same thing that winit does: it uses the scale-factor when doing pixel-scrolling. 229f7e4 That makes scrolling a lot faster. It still feels a bit off though. Maybe we need a logarithmic-scale here? But then again: VS Code does its own thing and has really fast and aggressive scroll. So maybe we need to lean into that direction completely?

[szlend]

• The display-link branch in Direct mode feels much smoother now. However the Composited mode is now the laggy one.
• In the Metal HUD I still see FPS alternating between 60fps and 120fps exactly. Is Zed running at vsync and Metal just throws the extra frames away? The M1+ laptops should support variable refresh rates so I would expect framerates in-between as well. I suspect this is what makes the scrolling actually feel choppy.
• I'm not sure if I like the new scrolling behavior. I thought the old one was fine (I didn't actually notice the difference to vscode until I compared the two side by side). But the new scrolling behavior immediately feels off - way too twitchy.

[mrnugget]

In the Metal HUD I still see FPS alternating between 60fps and 120fps exactly. Is Zed running at vsync and Metal just throws the extra frames away? The M1+ laptops should support variable refresh rates so I would expect framerates in-between as well. I suspect this is what makes the scrolling actually feel choppy.

Whoa, that's really interesting. On my M3 I get variable FPS, up to 120fps, but it's never really exact. I'm going to later try this on the M1 I have here.

And yes, the display-link branch is essentially handing the reigns to the OS so it can request a frame when it needs to, which is how Neovide did it too: neovide/neovide#2102 I'm still not 100% convinced of this approach here and what the HUD says.

So overall you would say the display-link branch is not an improvement because Direct is smoother but composite is laggy?

[szlend]

Whoa, that's really interesting. On my M3 I get variable FPS, up to 120fps, but it's never really exact. I'm going to later try this on the M1 I have here.

Note that I'm ignoring the average FPS and only looking at min, max framerate and the pre chart.

See the pre and fps times match vsync exactly. The pre chart shows the spikes over time and they always exactly double.

So overall you would say the display-link branch is not an improvement because Direct is smoother but composite is laggy?

Side-grade yeah. I usually program in full screen so for me it's an improvement :)

[mrnugget]

That does look like it's working as intended though, right? FPS is variable between 60 and 120hz here.

[szlend]

That does look like it's working as intended though, right? FPS is variable between 60 and 120hz here.

No, the FPS shown is average FPS. If I have one frame rendered at 60fps intervals and two frames rendered at 120fps intervals, then the average framerate is 80fps.

Look at the blue spikes in the Pre chart. It's alternating between 8.33ms and 16.67ms.

[mrnugget]

Ah, I see what you're saying. It's not really variable, but only flipping between 60 and 120hz?

[diocletiann]

I think it would help provide consistent feedback if you added smooth scrolling to keyboard-activated scroll commands, that way everyone can hold up/down or pgup/pgdn and compare at the same speed, in the same direction.

[szlend]

@mrnugget Whatever you did in optimistic-draw, Composite mode feels butter smooth! Best one yet, constant 120fps.

Still feels laggy in fullscreen (Direct mode) though. @diocletiann could you check if that's the case for you as well?

[diocletiann]

@szlend fullscreen feels pretty good as well, but I can't get the hud to show up so I can't tell if it's direct mode or what the real numbers are.

[mrnugget]

Another update here: @as-cii @nathansobo @maxbrunsfeld found another fix/improvement here #7253. It's already on main, so it would be very interesting to see if someone in here now notices differences when creating a --release build on main. (There also will be patch/preview release later today, I'm sure.)

[szlend]

master is perfectly smooth in Composited mode and pretty good in Direct as well. Most balanced so far. I don't get why Direct mode performs worse. It alternates between 60 and 120fps even when not touching the input. It was very smooth in the display-link branch though. I checked out the branch again just to compare/confirm.

So for me these ones are smooth now:

• Composited: master, optimistic-draw
• Direct: display-link (and pretty good in master too)

[mrnugget]

Yup. I haven't talked to the others since the fix was merged, so I might be off, but I think we have to combine both approaches: display-link and what's on main.

[mrnugget]

@szlend I just rebased display-link onto main, if you want to give that a shot. (Edit: I also fixed an earlier mistake of mine when I reverted the wrong commit, not the boosted-scrolling commit 🤦 )

[szlend]

@szlend I just rebased display-link onto main, if you want to give that a shot. (Edit: I also fixed an earlier mistake of mine when I reverted the wrong commit, not the boosted-scrolling commit 🤦 )

Tried a0c10abe. Composite is just as choppy as before on this branch. It's choppy while not touching any input (from scrolling intertia), so those input optimizations on main probably have no effect.

FWIW I rebased optimistic-draw on main and that one seems to be the smoothest one in both rendering modes.

[mrnugget]

Oookay, I probably have some very good news here: @as-cii made the latest fix on main work and it's just been released in the latest Preview version: 0.121.2-pre.

Can you all try that out and see if you still have the same problem?

@haze reported that scrolling is now much better on their M3 Max 14". Previously the blue line in the Metal HUD was jittery (wheras mine was flat with spikes), now it's a lot better.

[diocletiann]

Flat blue with spikes on my M1 Max. Feels great.

[rev4324]

Just tried latest preview, and I think the issue is solved. Blue line on mine is flat, with spikes appearing as I touch the trackpad, but I'm not able to feel any chopiness. Pre is around 4ms when I scroll, while GPU is around 2ms. It feels as good as e.g. Finder now, much better than VS Code.
Congrats guys and thank you!

[szlend]

0.121.2-pre is perfectly smooth in Composited mode, but still laggy in Direct mode (a ton of blue spikes). So for me at least this is not 100% fixed. The optimistic-draw branch paired with the input optimizations on main is the only one that works well in both modes.

It would be great if anyone reporting this as fixed could double check their rendering mode with MTL_HUD_ENABLED=1 and maybe try forcing it into Direct mode to compare. Usually using the MacOS fullscreen option forces it into Direct mode. Note that everything else (dock, menu bar, etc) has to be hidden for MacOS to switch to Direct rendering.

You can launch the Metal HUD from the terminal for any Zed app bundle like so:

$ MTL_HUD_ENABLED=1 <path_to_zed>.app/Contents/MacOS/zed

Edit: I'm getting as bad as 20fps lows (50ms pre) around line 8750 in types.ts. Everything is fine as soon as I switch to Composited.

[mrnugget]

@szlend can you try out main again? This has been merged now too: #7347

[oliver-kriska]

For me it's much faster, FPS around 140, measurements log around 2-3ms, previously +5-7ms.

CleanShot.2024-02-05.at.09.30.28.mp4

[szlend]

@szlend can you try out main again? This has been merged now too: #7347

It's prefect now! I can't get it to drop a single frame in Direct mode. Great job on this, and thanks for bearing with me :)

[mrnugget]

Perfect! Then I'm going to close this issue, since everybody seems happy with current main. Thanks everybody for helping out here!

[activenode]

I cannot exactly tell what it is but on a super-high-end machine (Mac, M3 Max, 96gb ram) with 2 external monitors I do run zed vertically on an LG QHD (not sure if it's anything to do with the monitor here but it's the only monitor I code on so also the only one I experience this with, but next time this appears I'll move it to a different window to see if it makes a difference).

Anyway, what happens is an EXTREMELY laggy behaviour (unusably laggy) . But it doesn't happen always, but often.

I don't know what happens really, but I wanted to report that this happens .

I never had this problem with my M1 Pro Macbook which had 32gb ram. It seems that this high-end machine somehow does something different which causes ZED to fail.

Been using ZED as my primary editor lately but this brings me back to VSCode

[mrnugget]

Does it go away when you disable the scrollbar?

[activenode]

Does it go away when you disable the scrollbar?

hard to tell. I'll try to reproduce it.

[R4zeel]

I think that i'm encountering the same issue: while in fullscreen scrolling feels laggy, definitely below 60 fps. When editor not in fullscreen mode - everything is fine.
Running zed on M3 Pro, 18gb RAM.

[activenode]

I think that i'm encountering the same issue: while in fullscreen scrolling feels laggy, definitely below 60 fps. When editor not in fullscreen mode - everything is fine. Running zed on M3 Pro, 18gb RAM.

That relates.

[mrnugget]

Can you try it with MTL_HUD_ENABLED=1? Are there any messages in the logs? Can you try disabling the scrollbar?

[R4zeel]

/bin/launchctl setenv MTL_HUD_ENABLED 1

Sure, i disabled the srollbar and turned on MTL_HUD, made a screen record but i'm afraid that for some reason on record there is no visual difference between fullscreen and windowed mode, hope i'm not imagining things

EDIT:
attached video file

d822410c-4e60-4ab6-b100-f6593584914d.mp4

[mrnugget]

but i'm afraid that for some reason on record there is no visual difference between fullscreen and windowed mode, hope i'm not imagining things

Hehe, we've all been there. What you can do is record with your phone or another camera — that's what I did in the past. It helps because it's not mucking with macOS' compositor.

[R4zeel]

/bin/launchctl setenv MTL_HUD_ENABLED 1

Tried to record on my phone, had to reduce quality to upload here but i hope the difference can be seen

img-3466_Cw84tvnF.mp4

[mrnugget]

Hmmm, I don't see a difference, but I also don't think there's anything we can do here as long as macOS reports 120fps in both modes, which it does here, right?

[R4zeel]

Hmmm, I don't see a difference, but I also don't think there's anything we can do here as long as macOS reports 120fps in both modes, which it does here, right?

Yeah, i'm not sure how could i present this data correctly, so i'll stick to windowed mode for now
Maybe it's just my eyes bugging out :)
Thank you for reply though, Thorsten!