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

Frame rate drop caused by high polling rate mouse #12679

Open
benkyoujouzu opened this issue Mar 24, 2024 · 5 comments
Open

Frame rate drop caused by high polling rate mouse #12679

benkyoujouzu opened this issue Mar 24, 2024 · 5 comments
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times S-Blocked This cannot move forward until something else changes

Comments

@benkyoujouzu
Copy link

benkyoujouzu commented Mar 24, 2024

Bevy Version

0.13.1

System Information

SystemInfo { os: "Windows 11 Home", kernel: "22631", cpu: "AMD Ryzen 9 7940HS w/ Radeon 780M Graphics", core_count: "8", memory: "15.2 GiB" }

AdapterInfo { name: "NVIDIA GeForce RTX 4060 Laptop GPU", vendor: 4318, device: 10464, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "536.45", backend: Vulkan }

What Went Wrong

I have a mouse that allows me to adjust its polling rate. There are no issues when the mouse's polling rate is below 2000Hz. However, when I set the polling rate to 4000Hz, even in the simplest scenes, rapidly moving the mouse causes a significant drop in frame rate, with the maximum frame time increasing from around 10ms to about 80ms. Minimal example

1000Hz:
1000Hz_frame_time

4000Hz:
4000Hz_frame_time

What You Did

Since I haven't encountered similar issues in Godot and some games, it likely isn't a problem with the performance of my computer.

I tried using PresentMode::Fifo, PresentMode::Mailbox, and PresentMode::Immediate, but the frame drops did not improve.

I attempted the method from SDL#8756 using GetRawInputBuffer to acquire raw mouse input in a dedicated thread (my code), yet there was still no improvement.

Tracing data shows a lot of CursorMoved events between two frames when using a 4000Hz polling rate. I tried commenting out the code handling CursorMoved in bevy_winit and setting event_loop.listen_device_events(DeviceEvents::Never), but these did not solve the problem.

1000Hz:
1000Hz_trace

4000Hz:
4000Hz_trace

I suspect that some logic within bevy_winit or winit might be causing the stutter with high polling rate mice, but I haven't identified the cause. Do you have any idea?

@benkyoujouzu benkyoujouzu added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Mar 24, 2024
@alice-i-cecile alice-i-cecile added A-Input Player input via keyboard, mouse, gamepad, and more C-Performance A change motivated by improving speed, memory usage or compile times A-Windowing Platform-agnostic interface layer to run your app in and removed S-Needs-Triage This issue needs to be labelled labels Mar 25, 2024
@alice-i-cecile
Copy link
Member

Are you able to reproduce this is in pure winit? Or in other front-ends that use winit, like eframe or I believe fyrox?

@alice-i-cecile alice-i-cecile added the S-Needs-Investigation This issue requires detective work to figure out what's going wrong label Mar 25, 2024
@benkyoujouzu
Copy link
Author

Are you able to reproduce this is in pure winit? Or in other front-ends that use winit, like eframe or I believe fyrox?

I've tested the egui_demo_app and a demo in the fyrox tutorial, and both experience significant frame rate drops when using a high polling rate mouse. Therefore, it's likely that the problem lies within winit.

I found a winit issue that may be related to this problem: rust-windowing/winit#1418

@alice-i-cecile alice-i-cecile added S-Blocked This cannot move forward until something else changes and removed S-Needs-Investigation This issue requires detective work to figure out what's going wrong labels Mar 26, 2024
@alice-i-cecile
Copy link
Member

Awesome, that's very useful information. Thank you for investigating!

@benkyoujouzu
Copy link
Author

benkyoujouzu commented Mar 28, 2024

I found the problem and made a pull request to winit rust-windowing/winit#3609.

Edit: This breaks some handling of winit. Additional fixes needed.

@AuracleTech
Copy link

AuracleTech commented May 11, 2024

I found the problem and made a pull request to winit rust-windowing/winit#3609.

Edit: This breaks some handling of winit. Additional fixes needed.

On my opened issue on winit I noted that I tested your pull but with no success, it made no difference between before / after the pull was added, if you have or want more information let me know.

Wanted to share this here because this is recent and seems highly relevant to this issue!

Note that I tried making a window with winit and with winapi directly, both had performance issues, so I suspect it's windows especially after my profiling results, so the only fix would be to find a workaround

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times S-Blocked This cannot move forward until something else changes
Projects
None yet
Development

No branches or pull requests

3 participants