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

[FEATURE MODIFICATION] EventChannel Refactor #1898

jaynus opened this issue Aug 23, 2019 · 0 comments


Copy link

commented Aug 23, 2019


We need to implement a new, immediate-mode eventing system for performance critical events to propagate on a single frame.

Possible Solutions Are

  • Implement a new same-frame eventing mechanism
  • Refactor usage of EventChannel across all systems to mitigate delays
  • Any other suggestions?


EventChannel from shrev currently has major design implications and performance pitfalls which were not considered on the intial design and usage. The system itself inherently introduces a single frame (16ms) delay on any event which hits the channel, as it is guaranteed to not be read until the next frame. Because of this, its usage across the engine is incurring 1-3 frame delays as certain critical events propagate across the engine.

For example, the Input system chain currently looks like this:
winit EventChannel (1 frame delay) -> InputSystem event channel (1 frame delay) -> Renderer pre-render frames (up to 3 frames delay!) Finally stuff is updated (maybe another frame delay).

This is giving us at a minimum, a 32ms delay for input to actually register. In practice, we are seeing 3-5 frame delays in input, adding up to 100ms input delays. This is unacceptable, and just is the best example of why this design is inherently flawed for its current use in our engine. It is still applicable as a general purpose event channel, but for many critical uses it needs to be phased out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.