Vulkan: Editor drawing is delayed by one frame

[feelingsonice]

Godot version

4.0 RC6

System information

Apple M2 Max, 96 GB Mem

Issue description

Potentially related to #71795, but that issue seems to be on Windows.

As this question in the Discord channel as well so linking it here.

The editor feels laggy and sometimes unresponsive. i.e. clicking on things, hovering over UI elements.

The weirdest thing is when I try to screen record it (Mac’s built-in screen record tool), the problem disappears. I had to use my phone to capture this.

The video shows general unresponsiveness when hovering over the node creation buttons, but the issues exists almost elsewhere in the editor as well.

IMG_0757.mov

Things I have tried so far:

• quitting and restarting the editor
• removing and starting a new project
• change to a different display (in the video I'm using an external display), including switching to my built-in display.

Enabling continuous update in editor settings seen to have improve the issue a little but the problem is still largely there.

Steps to reproduce

N/A

Minimal reproduction project

Any new project.

[Calinou]

Can you reproduce this after switching the rendering method to Compatibility in the top-right corner of the editor?

[feelingsonice]

@Calinou no, the problem is gone after switching Compatibility. I was on Mobile rendering.

[Calinou]

When using the Mobile renderer, can you reproduce this after changing the V-Sync mode to Disabled in the Project Settings, then restarting the editor? (This project setting also affects the editor.)

[feelingsonice]

@Calinou Yes it's still there.

BTW, I see you changed the title to say "delayed by one frame". I'm not entire sure what I'm talking about, but it doesn't feel like it's just delayed by one frame. Sometimes when I click somewhere it feels like the editor froze for a split second because it seems like my input (click) didn't register.

[Calinou]

This issue reminds me of #23069, which was an issue scoped to Intel IGPs on Windows.

[feelingsonice]

Here, I added another video, hopefully it helps.

It's hard to show this, but at 0:04 in the video, I actually clicked on the "3D" tab, but it didn't register right away, instead, moving my mouse triggered the "previous" click.

The sequence of actions were:

* -> click on "Script" -> move mouse to "3D" -> click -> *nothing happens* -> move mouse -> tab switched over to "3D"

IMG_0758.mov

[Calinou]

Moving the mouse eventually triggered a redraw, as you moved the mouse cursor away from the 3D button (which causes its hover state to be disabled).

You can see when the editor redraws by enabling Interface > Editor > Show Update Spinner in the Editor Settings. I recommend keeping it enabled when troubleshooting editor issues in general 🙂

[feelingsonice]

It's prob worth noting that this happens in the script editor as well, but unlike stated above, doing some additional action don't trigger the "previous" action. It just freezes for a split second "self-resolves".

[feelingsonice]

And again, I double confirmed this, because it seemed extra weird to me -- when screen recording using Mac's built-in screen recorder (cmd + shift + 5), this problem complete disappears.

[lostminds]

I'm not seeing this on my intel-based iMac so maybe it's something related to the new Apple Silicone processors or the graphics cards in them?

If you click the three little dots menu in the top left corner of a 3d-viewport there's a toggle to "Show frame time" that will show you the editor viewport update fps. Perhaps that could offer some information to see if the editor is actually updating slowly all around, or if it's something related only to the UI redrawing or reacting to events.

Some speculation: If the reported fps is displayed as high but visual updating is slow one thing to investigate could be if there's something in the window server compositing of window buffers that is going wrong. It could be that Godot is drawing into the window back buffer at the correct frequency, but for some reason it is not composited to the screen by the system window server. This could also explain why the issue would go away when recording the screen, as maybe that could cause some more aggressive flushing of the window server back buffers.

[Calinou]

Can you reproduce this if you enable Single Window Mode in the Editor Settings then restart the editor?

[feelingsonice]

Hmmmm so I unplugged my external displays and the problem disappeared. This happened independent of the Single Window Mode @Calinou

[feelingsonice]

I managed to pin point to the problem to one specific monitor (dell p2720dc), which is using USB-C to connect to my MBP. I haven't tried if the problem can be reproduced if I switch to HDMI or if other monitors have similar problems when connecting using USB-C.

Either way, since the problem is very specific to my setup, closing this.

[Calinou]

I wonder if this is caused by macOS USB-C display support being limited to 60 Hz, but since your MBP's display is 120 Hz, this causes V-Sync (or some other kind of FPS limiter) to screw up.

Can you reproduce this if you force your MBP's internal display to run at 60 Hz?

[feelingsonice]

@Calinou I have 2 external display, dell p2720dc and dell s2716dg. This problem only occurs on the p2720dc. The other one, s2716dg, although does support 144hz refresh rate, is connected via HDMI and so the refresh rate is is capped at 60hz as well.

[feelingsonice]

It might also have something to do with the fact that I'm using the p2720dc as a USB hub as well, so there's 2way communications in the USB. My mouse, keyboard, and all input that's happening is going through the monitor's USB hub.

[feelingsonice]

The problem is gone after switching to HDMI.