Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very high latency / judder on egui_wgpu + Vulkan + X11 #5089

Closed
valadaptive opened this issue Sep 7, 2024 · 5 comments
Closed

Very high latency / judder on egui_wgpu + Vulkan + X11 #5089

valadaptive opened this issue Sep 7, 2024 · 5 comments
Labels
bug Something is broken

Comments

@valadaptive
Copy link
Contributor

valadaptive commented Sep 7, 2024

Describe the bug

On X11, with egui_wgpu and Vulkan, with present_mode set to the default of PresentMode::AutoVsync (which resolves to PresentMode::Fifo, there is far more latency than the 3 frames' worth that wgpu claims, and there seem to be occasional "blips" where the framerate tries to catch up:

Peek.2024-09-07.18-39.mp4

To Reproduce
Steps to reproduce the behavior:

  1. Run the egui demo app with wgpu, on Linux, within an X11 session
  2. Try dragging a slider, or a similar "mouse-following" widget
  3. Observe the latency and hitches

Expected behavior

There should be a reasonably low amount of latency

Screenshots
See above

Desktop (please complete the following information):

  • OS: Fedora 40 on Xfce, w/ NVIDIA

More Information

The examples within the wgpu repository seem to run without any judder, which makes me suspect something in egui_wgpu.

@valadaptive valadaptive added the bug Something is broken label Sep 7, 2024
@valadaptive
Copy link
Contributor Author

With the CPU graph in the demo app, you can see a bit more of the weird frame pacing I'm talking about. There are these weird gaps in the graph:

Peek.2024-09-07.19-00.mp4

@valadaptive
Copy link
Contributor Author

I think what's going on here is that the frame pacing is slightly too fast (notice how it seems to be around 62 FPS in the above recording). This means that frames are submitted to the queue more quickly than they are popped from it, causing ever-increasing latency since the later frames take longer to reach the front of the queue. The judders/gaps are caused by it "catching up" and not submitting any more frames to the queue until all the current ones are processed.

@valadaptive
Copy link
Contributor Author

It seems this goes a bit deeper. With compositing disabled, the issue appears only on eframe. With compositing enabled, it is reproducible in the wgpu demos as well. I'm using XFCE (with xfwm4), for reference.

@emilk
Copy link
Owner

emilk commented Sep 10, 2024

@valadaptive
Copy link
Contributor Author

Looking at the actual frame times, this actually happens in the wgpu demos always. Disabling compositing somehow hides it.

@valadaptive valadaptive closed this as not planned Won't fix, can't repro, duplicate, stale Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken
Projects
None yet
Development

No branches or pull requests

2 participants