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

Refactor tonemapping example's image viewer update into two systems #11519

Merged
merged 4 commits into from
Jan 27, 2024

Conversation

rparrett
Copy link
Contributor

Objective

Alternative to #11515.

Fixes change detection being triggered on the "image viewer image material" every frame.

Solution

  • Split the megasystem into two separate systems: one to handle drop events, and one to handle asset change events.
  • Move the event reader iteration "outside." so that we're only doing stuff when there are events.
  • Flatten some of the more extreme nesting
  • Other bits of cleanup, removing an unnecessary clone and unused variable.

I think these systems can even run in parallel now, not that it particularly matters.

@alice-i-cecile alice-i-cecile added C-Bug An unexpected or incorrect behavior A-Rendering Drawing game state to the screen C-Examples An addition or correction to our examples labels Jan 25, 2024
@rparrett rparrett changed the title Refactor image viewer update into two systems Refactor tonemapping example's image viewer update into two systems Jan 25, 2024
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 27, 2024
@alice-i-cecile alice-i-cecile 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 Jan 27, 2024
Merged via the queue into bevyengine:main with commit 7da144b Jan 27, 2024
26 checks passed
tjamaan pushed a commit to tjamaan/bevy that referenced this pull request Feb 6, 2024
…evyengine#11519)

# Objective

Alternative to bevyengine#11515.

Fixes change detection being triggered on the "image viewer image
material" every frame.

## Solution

- Split the megasystem into two separate systems: one to handle drop
events, and one to handle asset change events.
- Move the event reader iteration "outside." so that we're only doing
stuff when there are events.
- Flatten some of the more extreme nesting
- Other bits of cleanup, removing an unnecessary clone and unused
variable.

I think these systems can even run in parallel now, not that it
particularly matters.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior C-Examples An addition or correction to our examples 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