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

Frequent dropped frames and audio underruns in Firefox #251

Closed
lukexor opened this issue May 28, 2024 · 1 comment · Fixed by #286
Closed

Frequent dropped frames and audio underruns in Firefox #251

lukexor opened this issue May 28, 2024 · 1 comment · Fixed by #286
Labels
bug Something isn't working web Web platform related

Comments

@lukexor
Copy link
Owner

lukexor commented May 28, 2024

Easy to reproduce:

  1. Visit https://lukeworks.tech/tetanes-web
  2. Load Homebrew Rom -> AO Demo
  3. Let the intro music play for a few seconds

Plays smoothly on most major browsers (Chrome, Safari, Edge) except Firefox.

Profiling shows jank animation frames any time there are GC pauses.

There should be a nominal amount of allocations per frame, most of which are outside of the control of tetanes or tetanes-core. e.g. events from winit and the event loop call to request_animation_frame. I've yet to discover any solutions that reduce these GC pauses for a smooth framerate.

List of things tried with little to no effect:

  • Disable NTSC filter (reduces CPU usage)
  • Hide menu bar (removes string allocations for egui menus)
  • Disable cycle accurate (reduces CPU usage)

Firefox stable and Firefox nightly both have this issue across Linux, macOS, and Windows platforms.

@lukexor lukexor added bug Something isn't working web Web platform related labels May 28, 2024
@lukexor lukexor assigned lukexor and unassigned lukexor May 28, 2024
@lukexor
Copy link
Owner Author

lukexor commented May 29, 2024

More investigation has shown that the main culprit for GC pauses and large amounts of CPU time are the construction and dropping of the AbortController signal used by the Scheduler inside winit which comes from using ControlFlow::Poll.

Creating and destroying these constantly per-frame seems to really stress out the GC and it turns out to be unneeded. By always doing ControlFlow::WaitUntil with either the next repaint time, or 16ms (60fps) performance is much improved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working web Web platform related
Projects
None yet
1 participant