Wayland: Shader TIME is unreliable (slow shaders) due to frame pacing method

[Riteo]

Tested versions

• Reproducible in 4.3.dev [b4e2a24]
• Not reproducible in anything earlier than 4.3.dev [7e0f7d3] (specific to the Wayland backend)

System information

Godot v4.3.dev (b4e2a24) - Arch Linux #1 SMP PREEMPT_DYNAMIC Thu, 01 Feb 2024 10:30:35 +0000 - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 6650 XT (RADV NAVI23) () - AMD Ryzen 5 2600 Six-Core Processor (12 Threads)

Issue description

On Wayland, ideally, the compositor tells us when to draw. The driver handles vertical synchronization by waiting indefinitely until we get a "frame event".

As a render-bound application, we can't rely on this feature, as we'd stall the main loop indefinitely if the window is hidden or just occluded, so we handle those events manually by using a bunch of hacks to constantly tick at a high fixed rate (2000 Hz) and trigger the renderer only exactly when we get a frame event.

Unfortunately, there seems to be an edge case where the shaders' TIME variable is step in 2000ths-of-a-second increments instead of the actual render rate, slowing them considerably. The FPS are also being reported incorrectly to 2000 FPS but that's not intrinsic to the problem.

In other words, we're ticking at a very high fixed rate and the renderer is getting confused, slowing shaders down.

This approach is pretty overkill and, although it could definitely be improved (such as by dynamically changing the tick rate), I think some different approach such as the one described in #87750 would be a better option, all in all, which would also fix this issue.

For more info see this post by emersion which describes the problem in more detail, although we can't use their same approach.

See also #82222 for a deeper analysis and tentative fix of this general main loop edge case.

Steps to reproduce

1. Edit the MRP with a Wayland-enabled build (requires commit e0f7d3abd4a02f423a5b95616840e028a9af7fa or later).
2. If needed change the target_refresh_rate variable of the mrp.gd script to match the refresh rate of the screen you're going to run the MRP on.
3. Run the project and notice how the shader-modulated icon on the left is going extra slow compared to the process equivalent.
4. With the aid of tools such as MangoHud or mesa's debug layers, notice how the reported FPS of 2000 is not correct (it's the tick rate, not the framerate).
5. Press T to limit the FPS and ticking rate to the refresh rate set.
6. Notice how the shader is now running properly.

Minimal reproduction project (MRP)

graphics-delta-mrp.zip