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

Add a variant of Events::update that returns the removed events #9542

Merged
merged 6 commits into from
Aug 28, 2023

Conversation

JoJoJet
Copy link
Member

@JoJoJet JoJoJet commented Aug 22, 2023

Objective

Every frame, Events::update gets called, which clears out any old events from the buffer. There should be a way of taking ownership of these old events instead of throwing them away. My use-case is dumping old events into a debug menu so they can be inspected later.

One potential workaround is to just have a system that clones any incoming events and stores them in a list -- however, this requires the events to implement Clone.

Solution

Add Events::update_drain, which returns an iterator of the events that were removed from the buffer.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Aug 23, 2023
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like a bit of reassurance that this compiles down to the same code as a naive "duplicate the code" solution, but I won't block on it.

A doc test would be good too.

@JoJoJet
Copy link
Member Author

JoJoJet commented Aug 26, 2023

I'd like a bit of reassurance that this compiles down to the same code as a naive "duplicate the code" solution, but I won't block on it.

Calling .drain() doesn't actually move any memory around. All of the drained elements remain the vector's original buffer, until they get removed by Iterator::next. When the iterator gets dropped, any unyielded elements get dropped (if you're only draining part of the iterator, any un-drained elements at the end get ptr::copy-ed back into place at this point. Since we're draining the entire vec with .., this step gets skipped). So, if you call .drain(..) and then drop the returned iterator, it doesn't do any more actual work than calling .clear(), save for some cheap glue code that should be trivial to optimize away.

I will add a test or two.

@hymm hymm added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Aug 28, 2023
@alice-i-cecile
Copy link
Member

@JoJoJet this needs to have merge conflicts resolved, then I'll merge :)

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Aug 28, 2023
Merged via the queue into bevyengine:main with commit c440de0 Aug 28, 2023
21 checks passed
@JoJoJet JoJoJet deleted the update-drain branch August 28, 2023 20:53
rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024
…vyengine#9542)

# Objective

Every frame, `Events::update` gets called, which clears out any old
events from the buffer. There should be a way of taking ownership of
these old events instead of throwing them away. My use-case is dumping
old events into a debug menu so they can be inspected later.

One potential workaround is to just have a system that clones any
incoming events and stores them in a list -- however, this requires the
events to implement `Clone`.

## Solution

Add `Events::update_drain`, which returns an iterator of the events that
were removed from the buffer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants