This is a seperate discussion thread opened in tandem with: https://github.com/amethyst/amethyst/issues/1898 to discuss why EventChannel is currently bad.
I’ve copied the details from that ticket here.
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.