bevyengine / bevyengine/bevy

Configurable (opt-in) event timestamps

Open
#12,635 0 comments 0 reactions 0 assignees View on GitHub
A-ECS C-Feature
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.