Configurable (opt-in) event timestamps
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## What problem does this solve or what need does it fill?
For the purposes of age-based event clearing, our current solution is still kind of arbitrary. If bevy users/devs could opt-in to applying timestamps when their events are enqueued, this would give them accurate-enough event memory management.
However, we **would not** want this for input events, as timestamps for those should be sourced directly from winit (eventually).
## What solution would you like?
Therefore, a user configurable solution would be best:
```rust
// What this could look like from a user perspective, subject to bikeshedding:
#[derive(Event)]
#[event(timestamp = "on_queue")]
pub struct MyEvent {
pub actor: Entity,
}
// Not covered by this issue, but for comparison to what an input event *could* define:
#[derive(Event)]
pub struct KeyboardEvent {
#[event(timestamp)]
pub timestamp: Instant,
pub keycode: KeyCode,
}
```
When an event's timestamp is older than both `Time` and `Time`, it is removed from its event storage.
**Importantly, however it is implemented should remain a zero-cost abstraction: events which aren't using timestamps should not have their memory footprint increased.**
## Additional context
Initially proposed [on discord](https://discord.com/channels/691052431525675048/691052431974465548/1220486246472749066):
> doot — Today at 4:36 PM
We could add on-queue timestamps now but not use them as the source of truth for input events. Use them only for clearing old events
Because worst case, they're later than the input events, but that's not important for event clearing
> Alice 🌹 — Today at 4:37 PM
Yeah, I would accept a PR for this if it's opt in
I don't really want to double or more the memory footprint of all events
Contributor guide
Research direction
Start by tracing the Event derive example, event storage, and the Time and Time references named in the issue. Determine how opt-in enqueue timestamps could preserve zero-cost storage for other events and how timestamp-based clearing should work. Done means the design and implementation meet the opt-in behavior without affecting input events.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- game-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100