Derive `Clone` for `InfiniteGrid`so that `FromTemplate` can be
auto-derived on it, making it spawnable with BSN.
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
The new Diagnostic Overlay has some issues:
- It uses a fullscreen Node that blocks all clicks, preventing other UI
items from being clicked by default
- It doesn't implement Default / Clone, so it isn't compatible with BSN
- The font size isn't configurable (small by default is good, but it
might be too small for some peoples' preferences)
## Solution
Fix all of those things.
This should ship in 0.19 because it is pretty broken without the click
passthrough fix. This doesn't need an RC to test because it is a new
feature, very broken without this fix, and it is disabled by default.
---------
Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
# Objective
Allow materials to use pipeline constants ([pipeline-overridable
constants](https://www.w3.org/TR/WGSL/#override-decls)).
They are already available in wgpu, but bevy didn't expose them.
## Solution
Expose constants in `RenderPipelineDescriptor` &
`ComputePipelineDescriptor`, allowing materials to specify them in their
specilize function.
**Note:** I had to remove the `Eq` derive from
`ComputePipelineDescriptor`, `VertexState` and `FragmentState`, due to
the new f64 field. It was already a bit inconsistent with
`RenderPipelineDescriptor` not having it.
## Testing
- Ran `cargo check`
- Created an example & ran it
- Couldn't run `cargo test` due to it taking looots of disk space to
run, but I have a hard time seeing it break something at runtime
## Showcase
See the added example, where pipeline constants are used to change the
`LEVELS` override in WGSL.
<img width="760" height="289" alt="Screenshot from 2026-05-31 09-46-05"
src="https://github.com/user-attachments/assets/6902757c-aea4-4b91-9ff0-e653ce4c3448"
/>
# Objective
Resolves#21902.
## Solution
This PR adopts a relatively transparent approach to reduce the GPU
vertex buffer size. On CPU-side mesh can still use uncompressed Float32
data, and users are not required to insert compressed vertex formats.
The vertex data is automatically processed into
lower-precision/octahedral encoded data when uploading to the GPU.
To enable vertex attribute compression, just set the
`attribute_compression` field of Mesh, or set
`mesh_attribute_compression` of GltfLoaderSettings. If enabled, normal
and tangent will be octahedral encoded Unorm16x2, uv0, uv1, joint weight
and color will be corresponding Unorm16 or Float16. I also provide
Unorm8x4 for vertex color if hdr isn't needed.
Update 2026-2-16
Removed previous approach that automatically compresses vertex buffer
according to flags when uploading to GPU. Instead, I added
`compressed_mesh` method to Mesh to construct compressed Mesh ahead of
time. GltfLoader can also opt-in mesh compressing when loading. I also
add an option to convert indices to u16, though I believe blender gltf
exporter already uses u16 indices when possible.
## Testing
Run `many_cubes`, `many_foxes`, `many_morph_targets` with
`--vertex-compression` to test 3d.
Run `bevymark` with `sprite_mesh` to test 2d, because `SpriteMesh` uses
compressed quad mesh now.
---------
Co-authored-by: Greeble <166992735+greeble-dev@users.noreply.github.com>
# Objective
Fix typos and other small issues in the documentation. I can drop the
changes to `bevy_reflect`'s and `bevy_anti_alias`'s crate descriptions
if it's a problem.
# Objective
- Fixes#24377
- One of the regressions was already fixed by #24019 . The other
regression (caused seemingly by merely adding TransformGizmo
functionality) revealed a potential system ordering issue when using the
`DiagnosticsOverlayPlugin`: If one setups `DiagnosticsOverlay`s in the
`Startup` schedule, the `build_overlays` observer could fail silently
because the `DiagnosticsOverlayPlane` (which is also created in the
`Startup` schedule) may not have been created yet.
## Solution
Move the system that sets up the`DiagnosticsOverlayPlane` into the
`PreStartup` schedule.
## Testing
- Copied the “What I did” section in
https://github.com/bevyengine/bevy/issues/24377 (`cargo run --release
--example scene_viewer --features="free_camera bevy_dev_tools"
assets/models/FlightHelmet/FlightHelmet.gltf` after the scene_viewer has
been modified as described). The overlay now appears and works
correctly.
# Objective
In #22966 the semantics of the `add` method on `SortedRenderPhase` was
changed from the items being cleared at the end of the frame, to items
being retained until they are removed. A new `add_transient` method was
added with the old functionality, but this is a big migration hazard
because it's a major semantic change that doesn't give any compiler
errors or warnings.
I discovered this after updating `bevy_vector_shapes` to the RC and
seeing drawings not being cleared properly.
## Solution
Rename `add` to `add_retained` both for clarity and to make old uses not
compile, so the affected users will know to look in the migration guide.
A sentence about this should be added to the migration guide if/when
this is backported to the 0.19 release branch.
## Testing
It compiles (hopefully).
# Objective
- bevy_city needed a way to merge all the `Mesh3d` from a `WorldAsset`.
Instead of keeping that function hidden inside bevy_city we can make it
public
## Solution
- Add `world_asset_helpers` to `bevy_dev_tools`. It's in
`bevy_dev_tools` because it depends on multiple different parts of bevy
and that's the only crate that users can use that already depends on a
lot of things.
- Add `marge_all_mesh_3d()` to `world_asset_helpers`
- Update bevy_city to use that helper
## Testing
- I ran bevy_city and the meshes were merged like they should
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
Fixes#23627.
`MeshPipelineViewLayoutKey` uses too many bindings even if features like
ssr, environment map are unused.
## Solution
Don't pre-allocate every combination that grows exponentially. Instead,
create mesh view bind group layout on demand so that we can add more
view keys to reduce unused bindings.
`MeshPipelineViewLayouts::get_view_layout` will be slower, but I'm not
sure how slow it is. My feeling is that the overhead is not high,
compared to when we clone it before.
## Testing
```
WGPU_SETTINGS_PRIO=webgl2 cargo r --example 3d_scene
cargo r --example ssr --features bluenoise_texture
cargo r --example ssao
cargo r --example irradiance_volumes
```
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
# Objective
According to #18900 , rename `MeshPipelineSet` to `MeshPipelineSystems`
for a consistent naming convention.
`MeshPipelineSet` was introduced in this cycle, so no migration guide
required.
## Testing
```
cargo run --example specialized_mesh_pipeline
```
# Objective
- Clean up our texture format handling.
- Fix#23732
- Get us closer to #22563
- It makes no sense for views to talk about being hdr or not. They have
a texture format, that's it. What does HDR shadows even mean lol
- Same for compositing_space
## Solution
- Remove ExtractedView::hdr
- Add ExtractedView::texture_format
- Move ExtractedView::compositing_space to
ExtractedCamera::compositing_space
- Add texture_format to a bunch of specialization keys instead of hdr
bool
- Convert VolumetricFogPipelineKey to not use flags and just use bool
and texture format
- Remove BevyDefault TextureFormat
- Remove ViewTarget TEXTURE_FORMAT_HDR
## Testing
- Pretty extensively test at this point
This has a migration guide.
---------
Co-authored-by: Willow Black <wmcblack@gmail.com>
Co-authored-by: Máté Homolya <mate.homolya@gmail.com>
Co-authored-by: Luo Zhihao <luo_zhihao@outlook.com>
Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
# Objective
Tries to fix#23143, fix#23144, and fix artifacts in the
`deferred_rendering` example when using the render debug overlays.
I'm using this to learn more about the renderer so I'm not 100%
confident here, but this is what my investigation found:
Before yeeting the render graph in #22144, the different nodes were a
lot more serial due to sync nodes like `EndMainPassPostProcessing` and
having to manually add edges. Now that stuff is more concurrent we're
dependent on the ambiguity checker to help us catch missing
dependencies, and it was even enabled for the render world recently.
However, all of the post processing systems depend on `&ViewTarget`,
which is read-only but has rendering side effects through
`post_process_write()`. This causes the render debug overlay to race
against SMAA/FXAA and potentially other effects as well.
After this stopped the flickering from the first issue, I noticed the
second issue and that the depth debug image was indeed blank. After some
digging and the helpful comment about deferred I tracked this down to
the early return in `run_prepass_system`. The comment above it seems
wrong to me: just because there's a deferred prepass it doesn't mean
that the forward bins are empty. There is also a
`deferred_prepass.is_none()` check before the depth texture copy that is
currently redundant, but would make sense without the early return.
After both of these fixes I can no longer reproduce the above 2 issues,
and all the debug overlays seem to make sense in the
`deferred_rendering` example.
## Solution
* Move the render debug overlay outside of PostProcess, and order
against relevant things.
* Don't unconditionally skip prepass based on deferred
## Potential future work
Maybe `ViewTarget` should be taken as mut, so future issues will be
caught by the ambiguity checker?
Should we have more system sets in the core pipeline, e.g. for debug
overlays and UI?
## Testing
See the reproductions in the issues, and try different examples with
`--features bevy_dev_tools`, like `cargo run --example
deferred_rendering --features bevy_dev_tools`
@ChristopherBiscardi it would be helpful if you can test this against
your project(s) as well.
# Objective
- Previously, if there was an error during the schedule initialize, the
schedule would **not** be re-inserted into the `Schedules` resource.
- The bespoke hokey-pokey was confusing enough, and Alice even pointed
it out! I just didn't know about this method :(
## Solution
- Use `schedule_scope` which does all the business of hokey-pokey, and
this currently handles errors for us!
## Testing
- Added a test for this.
# Objective
- A step towards #10981.
- Allow us to extract data from an app about the schedules.
Here are also some **non-goals** for this PR. These are left as future
work:
- Extract every piece of data in the schedule. I've focused on a rough
set of information that should let us visualization the most important
parts.
- Provide utilities for interpreting the data. This PR is focused on
just extracting the data, interpreting it comes next.
- Any sort of dot graph tools.
## Solution
- Create ser/de compatible structs for representing schedule data.
- Create a function to get schedule data from an initialized `Schedule`.
- Create a plugin to automatically extract the schedule data for every
schedule in the `App`.
- Note this doesn't include other subapps, I'll also leave that to
another PR.
- Make `bevy_ecs` return edges that build passes added.
- Make `bevy_ecs` return the "build metadata" to the caller, and also
trigger as an event.
## Testing
- Added tests!
- Added an example - it outputs a ron file. I assume its all valid.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
wgpu update for v29.
I have tested on macos m1, m5, and windows. Linux testing is
appreciated.
- [x] before merge, naga_oil and dlss_wgpu need to be published, and the
patches referencing their respective PRs removed from the workspace
Cargo.toml
##### other PRs
- naga_oil: https://github.com/bevyengine/naga_oil/pull/134
- dlss_wgpu: https://github.com/bevyengine/dlss_wgpu/pull/27
##### Source of relevant changes
- `Dx12Compiler::DynamicDxc` no longer has `max_shader_model`
- https://github.com/gfx-rs/wgpu/pull/8607
- `Dx12BackendOptions::force_shader_model` comes from:
- https://github.com/gfx-rs/wgpu/pull/8984
- Allow optional `RawDisplayHandle` in `InstanceDescriptor`
- https://github.com/gfx-rs/wgpu/pull/8012
- Add `GlDebugFns` option to disable OpenGL debug functions
- https://github.com/gfx-rs/wgpu/pull/8931
- Add a DX12 backend option to force a certain shader model
- https://github.com/gfx-rs/wgpu/pull/8984
- Migrate validation from maxInterStageShaderComponents to
maxInterStageShaderVariables
- https://github.com/gfx-rs/wgpu/pull/8652
- gaps are now supported in bind group layouts
- https://github.com/gfx-rs/wgpu/pull/9034
- depth validation changed to option to match spec
- https://github.com/gfx-rs/wgpu/pull/8840
- SHADER_PRIMITIVE_INDEX is now PRIMITIVE_INDEX
- https://github.com/gfx-rs/wgpu/pull/9101
- Support for binding arrays of RT acceleration structures
- https://github.com/gfx-rs/wgpu/pull/8923
- Make HasDisplayHandle optional in WindowHandle
- https://github.com/gfx-rs/wgpu/pull/8782
- `QueueWriteBufferView` can no longer be dereferenced to `&mut [u8]`,
so use `WriteOnly`.
- https://github.com/gfx-rs/wgpu/pull/9042
- ~bevy_mesh currently has an added dependency on `wgpu`, can we move
`WriteOnly` to wgpu-types?~ (it is in wgpu-types now)
- Change max_*_buffer_binding_size type to match WebGPU spec (u32 ->
u64)
- https://github.com/gfx-rs/wgpu/pull/9146
- raw vulkan init `open_with_callback` takes Limits as argument now
- https://github.com/gfx-rs/wgpu/pull/8756
## Known Issues
There is currently one known issue with occlusion culling on macos,
which we've decided to disable on macos by checking the limits we
actually require. This makes it so that if wgpu releases a patch fix,
bevy 0.19 users will benefit from occlusion culling re-enabling for
them.
<details><summary>More details</summary>
On macos, the wpgu limits were changed to align with the spec and now
put the early and late GPU occlusion culling `StorageBuffer` limit at 8,
but we currently use 9. [Filed in wgpu
repo](https://github.com/gfx-rs/wgpu/issues/9287)
```
2026-03-19T01:37:10.771117Z ERROR bevy_render::error_handler: Caught rendering error: Validation Error
Caused by:
In Device::create_bind_group_layout, label = 'build mesh uniforms GPU late occlusion culling bind group layout'
Too many bindings of type StorageBuffers in Stage ShaderStages(COMPUTE), limit is 8, count was 9. Check the limit `max_storage_buffers_per_shader_stage` passed to `Adapter::request_device`
```
</details>
solari working on wgpu 29:
<img width="1282" height="752" alt="image"
src="https://github.com/user-attachments/assets/4744faec-65c0-4a72-93e1-34a721fc26d8"
/>
---------
Co-authored-by: atlv <email@atlasdostal.com>
# Objective
- Bevy is now at a point where multiple people are experimenting with
editors and pretty much all of them need an infinite grid
- There are various techniques that can be used to render an infinite
grid without artifacts. This one fades out the lines that are too far
from the camera. The general idea is that the grid is rendered in a
fullscreen pass.
- [bevy_infinite_grid](https://github.com/fslabs/bevy_infinite_grid) is
maintained by foresight spatial labs. It has been used by foresight and
other third party projects in production for many years at this point.
This PR upstreams that crate with full permission from foresight.
## Solution
- Upstream bevy_infinite_grid
- A few minor changes were done to bring it in line with the rest of
bevy
- In the process of upstreaming I noticed a few minor issues that I
fixed like using a fullscreen triangle instead of a quad and using
bevy's View instead of custom one.
- The infinite_grid is currently part of bevy_dev_tools since we don't
have an editor crate but I suspect we'll want to move it to an editor
crate down the line. Although I'm sure projects will want to use this
even if they aren't using the official editor.
## Testing
- I tested the example to confirm it works
---
## Showcase
<img width="1280" height="720" alt="infinite_grid_cSJj0G02fP"
src="https://github.com/user-attachments/assets/cacddc5e-9a54-454b-aefa-b7829c34227a"
/>
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
- Continue render recovery effort #22761
- Part of goal #23029
- Reload gpu resources easily
## Solution
- Add an extension trait to insert resources on RenderStartup using
from_world
- replace almost every usage of init_resource that holds anything
derived from a RenderDevice with init_gpu_resource so that it may be
reinitialized on recovery
- Note: "almost every" because there is a handful of slightly more
involved cases I will leave to a follow ups.
## Testing
- render recovery example still crashes, i have a branch with it working
that i am just pulling out reviewable bits from
- we should also verify that this doesnt break examples, as it does
slightly modify behavior: gpu resources are initialized slightly later
than they used to be, because they wait until RenderStartup instead of
doing it immediately.
- i mostly want to get the largest part of the change out of the way
first
# Objective
- Convert `MeshPipelineViewLayouts` , `MeshPipeline` and
`RenderDebugOverlayPipeline` to `RenderStartup` system
## Solution
- Do the thing
## Testing
- Ran `animated_mesh` example
# Objective
- Allow users to specify a custom output directory for screen recordings
in `EasyScreenRecordPlugin`.
- Currently, recordings are always saved to the current working
directory with no way to configure the path.
## Solution
- Add an `output_dir: Option<PathBuf>` field to
`EasyScreenRecordPlugin`.
- When `None` (the default), recordings are saved in the current working
directory, preserving existing behavior.
- When `Some(path)`, recordings are saved in the specified directory.
The directory is created automatically if it does not exist.
- Update `RecordCommand::Start` to use `PathBuf` instead of `String`.
## Testing
- Verified compilation with `cargo check -p bevy_dev_tools --features
screenrecording`.
---
## Showcase
```rust
// Default: records to current working directory
app.add_plugins(EasyScreenRecordPlugin::default());
// Custom output directory
app.add_plugins(EasyScreenRecordPlugin {
output_dir: Some("recordings".into()),
..default()
});
```
This is part of #19731.
# Resources as Components
## Motivation
More things should be entities. This simplifies the API, the lower-level
implementation and the tools we have for entities and components can be
used for other things in the engine. In particular, for resources, it is
really handy to have observers, which we currently don't have. See
#20821 under 1A, for a more specific use.
## Current Work
This removes the `resources` field from the world storage and instead
store the resources on singleton entities. For easy lookup, we add a
`HashMap<ComponentId, Entity>` to `World`, in order to quickly find the
singleton entity where the resource is stored.
Because we store resources on entities, we derive `Component` alongside
`Resource`, this means that
```rust
#[derive(Resource)]
struct Foo;
```
turns into
```rust
#[derive(Resource, Component)]
struct Foo;
```
This was also done for reflections, meaning that
```rust
#[derive(Resource, Reflect)]
#[refect(Resource)]
struct Bar;
```
becomes
```rust
#[derive(Resource, Component, Reflect)]
#[refect(Resource, Component)]
struct Bar;
```
In order to distinguish resource entities, they are tagged with the
`IsResource` component. Additionally, to ensure that they aren't queried
by accident, they are also tagged as being internal entities, which
means that they don't show up in queries by default.
## Drawbacks
- Currently you can't have a struct that is both a `Resource` and a
`Component`, because `Resource` expands to also implement `Component`,
this means that this throws a compiler error as it's implemented twice.
- Because every reflected Resource must also implement
`ReflectComponent` you need to import
`bevy_ecs::reflect::ReflectComponent` every time you use
`#[reflect(Resource)]`. This is kind of unintuitive.
## Future Work
- Simplify `Access` in the ECS, to only deal with components (and not
components *and* resources).
- Newtype `Res<Resource>` to `Single<Ref<Resource>>` (or something
similair).
- Eliminate `ReflectResource`.
- Take stabs at simplifying the public facing API.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Dimitrios Loukadakis <dloukadakis@users.noreply.github.com>
# Objective
- Fixes#16751
## Solution
- `Assets::get_mut` now returns a wrapper `AssetMut` type instead of
`&mut impl Asset`.
- `AssetMut` implements `Deref` and `DerefMut`.
- `DerefMut` marks assets as changed.
- when dropped `AssetMut` will add `AssetEvent::Modified` event to a
queue only in case asset was marked as changed.
## Testing
- Did you test these changes? If so, how?
- No unit tests were added, change is pretty straightforward.
- Test project: https://github.com/MatrixDev/bevy-feature-16751-test.
- With change: ~100 fps.
- Without change: ~15 fps.
- Are there any parts that need more testing?
- I don't really see how this can break anything or add a measurable
overhead.
- `AssetEvent::Modified` will now be sent after the asset was modified
instead of before. It should not affect anything but still worth noting.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- Have a big amount of entities that constantly update their materials.
- Properties of those materials should be animated in a stepped maned
(like changing color every 0.1 seconds).
- Update material only if value has actually changed:
```rust
if material.base_color != new_color {
material.base_color = new_color;
}
```
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
- tested on macos (Mackbook M1)
- not a platform-specific issue
PS: This is my first PR, so please don’t judge.
# Objective
- Fixes#22736
## Solution
- Add and expose a system set (`EasyScreenRecordSystems`) for the
`Update` systems run in `EasyScreenRecordingPlugin`. Users who have apps
with behavior that depend on virtual time, and who want that behavior
recorded, should have their own `Update` systems run after
`EasyScreenRecordSystems`.
- While testing out recording, I found the `info` statements could be
improved slightly, so I added one and edited another.
## Testing
- I tested the reproduction example in #22736 and waited very patiently
for the video to process (A 6 second video took 5 minutes to save! Don’t
know if it’s just me… Maybe worth making an issue...). I used ffmpeg to
process the h264 file into an mp4, and it looks like I expect.
---------
Co-authored-by: François Mockers <francois.mockers@vleue.com>
# Objective
Add responsive font sizes supporting rem and viewport units to
`bevy_text` with minimal changes to the APIs and systems.
## Solution
Introduce a new `FontSize` enum:
```rust
pub enum FontSize {
/// Font Size in logical pixels.
Px(f32),
/// Font size as a percentage of the viewport width.
Vw(f32),
/// Font size as a percentage of the viewport height.
Vh(f32),
/// Font size as a percentage of the smaller of the viewport width and height.
VMin(f32),
/// Font size as a percentage of the larger of the viewport width and height.
VMax(f32),
/// Font Size relative to the value of the `RemSize` resource.
Rem(f32),
}
```
This replaces the `f32` value of `TextFont`'s `font_size` field.
The viewport variants work the same way as their respective `Val`
counterparts.
`Rem` values are multiplied by the value of the `RemSize` resource
(which newtypes an `f32`).
`FontSize` provides an `eval` method that takes a logical viewport size
and rem base size and returns an `f32` logical font size. The resolved
logical font size is then written into the `Attributes` passed to Cosmic
Text by `TextPipeline::update_buffer`.
Any text implementation using `bevy_text` must now provide viewport and
rem base values when calling `TextPipeline::update_buffer` or
`create_measure`.
`Text2d` uses the size of the primary window to resolve viewport values
(or `Vec2::splat(1000)` if no primary window is found). This is a
deliberate compromise, a single `Text2d` can be rendered to multiple
viewports using `RenderLayers`, so it's difficult to find a rule for
which viewport size should be chosen.
### Change detection
`ComputedTextBlock` has two new fields: `uses_viewport_sizes` and
`uses_rem_sizes`, which are set to true in `TextPipeline::update_buffer`
iff any text section in the block uses viewport or rem font sizes,
respectively.
The `ComputedTextBlock::needs_rerender` method has been modified to take
take two bool parameters:
```rust
pub fn needs_rerender(
&self,
is_viewport_size_changed: bool,
is_rem_size_changed: bool,
) -> bool {
self.needs_rerender
|| (is_viewport_size_changed && self.uses_viewport_sizes)
|| (is_rem_size_changed && self.uses_rem_sizes)
}
```
This ensures that text reupdates will also be scheduled if one of the text section's uses a viewport font size and the local viewport size changed, or if one of the text section's uses a rem font size and the rem size changed.
#### Limitations
There are some limitations because we don't have any sort of font style inheritance yet:
* "rem" units aren't proper rem units, and just based on the value of a resource.
* "em" units are resolved based on inherited font size, so can't be implemented without inheritance support.
#### Notes
* This PR is quite small and not very technical. Reviewers don't need to be especially familiar with `bevy_text`. Most of the changes are to the examples.
* We could consider using `Val` instead of `FontSize`, then we could use `Val`'s constructor functions which would be much nicer, but some variants might not have sensible interpretations in both UI and Text2d contexts. Also we'd have to make `Val` accessible to `bevy_text`.
## Testing
The changes to the text systems are relatively trivial and easy to understand. I already added a minor change to the `text` example to use `Vh` font size for the "hello bevy" text in the bottom right corner. If you change the size of the window, you should see the text change size in response. The text initially flickers before it updates because of some unrelated asset/image changes that mean that font textures aren't ready until the frame after the text update that changes the font size.
Most of the example migrations were automated using regular expressions, and there are bound to be mistakes in those changes. It's infeasible to check every single example thoroughly, but it's early enough in the release cycle that I don't think we should be too worried if a few bugs slip in.
---------
Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
# render-graph-as-systems
> [!NOTE]
> Remember to check hide whitespace in diff view options when reviewing
this PR
This PR removes the `RenderGraph` in favor of using systems.
## Motivation
The `RenderGraph` API was originally created when the ECS was
significantly more immature. It was also created with the intention of
supporting an input/output based slot system for managing resources that
has never been used. While resource management is an important potential
use of a render graph, current rendering code doesn't make use of any
patterns relating to it.
Since the ECS has improved, the functionality of `Schedule` has
basically become co-extensive with what the `RenderGraph` API is doing,
i.e. ordering bits of system-like logic relative to one another and
executing them in a big chunk. Additionally, while there's still desire
for more advanced techniques like resource management in the graph, it's
desirable to implement those in ECS terms rather than creating more
`RenderGraph` specific abstraction.
In short, this sets us up to iterate on a more ECS based approach, while
deleting ~3k lines of mostly unused code.
## Implementation
At a high level: We use `Schedule` as our "sub-graph." Rather than
running the graph, we run a schedule. Systems can be ordered relative to
one another.
The render system uses a `RenderGraph` schedule to define the "root" of
the graph. `core_pipeline` adds a `camera_driver` system that runs the
per-camera schedules. This top level schedule provides an extension
point for apps that may want to do custom rendering, or non-camera
rendering.
### `CurrentView` / `ViewQuery`
When running schedules per-camera in the `camera_driver` system, we
insert a `CurrentView` resource that's used to mark the currently
iterating view. We also add a new param `ViewQuery` that internally uses
this resource to execute the query and skip the system if it doesn't
match as a convenience.
### `RenderContext`
The `RenderContext` is now a system param that wraps a `Deferred` for
tracking the state of the current command encoder and queued buffers.
### `SystemBuffer`
We use an system buffer impl to track command encoders in the render
context and rely on apply deferred in order to encode them all.
Currently, this encodes them in series. There are likely opportunities
here to make this more efficient.
## Benchmarks
### Bistro
<img width="1635" height="825" alt="Screenshot 2026-01-15 at 7 57 40 PM"
src="https://github.com/user-attachments/assets/8e55a959-89a3-4947-bfc5-c04780f82e7b"
/>
### Caldera
<img width="1631" height="828" alt="Screenshot 2026-01-15 at 8 13 06 PM"
src="https://github.com/user-attachments/assets/e7e8ae0d-41c3-430f-8b4d-9099b3d922a0"
/>
## Future steps
There are a number of exciting potential changes that could follow here:
- We can explore adding something like a read-only schedule to pick up
some more potential parallelism in graph execution.
- We can use more things like run conditions in order to prevent systems
from running at all in the first place.
- We can explore things like automating resource creation via system
params.
## TODO:
- [x] Make sure 100% of everything still works.
- [x] Benchmark to make sure we don't regress performance
- [x] Re-add docs
---------
Co-authored-by: atlas dostal <rodol@rivalrebels.com>
# Objective
`LogDiagnosticsPlugin` prints the values on the `DiagnosticStore` to the
console, which is spam-y, create an alternative that is visual
## Solution
Create `RenderAssetsOverlayPlugin` to create an UI that presents the
data for the `MaterialAllocatorDiagnosticPlugin::<StandardMaterial>` and
`MeshAllocatorDiagnosticPlugin` on a draggable and collapsable window
## Testing
Enabled it on the `many_foxes` example
## Showcase
<img width="1920" height="1036" alt="image"
src="https://github.com/user-attachments/assets/f44b663b-cf77-4c18-8df8-48c9d2ec7fdd"
/>
<img width="1920" height="1036" alt="image"
src="https://github.com/user-attachments/assets/6d807092-bde3-4aef-af81-b6ac0d32ea1c"
/>
Upgrade to wgpu 28
> [!important]
> This can't merge until https://github.com/bevyengine/naga_oil/pull/132
does, and the dependency is updated from my fork to the release.
>
> Also requires wgpu 28 in dlss_wgpu:
https://github.com/bevyengine/dlss_wgpu/pull/17
> [!note]
> This does not enable mesh shaders, and neither does the naga_oil PR. I
chose to do an upgrade first, then go back and see about mesh shaders.
Here's a general list of changes and what I did. Commits are grouped by
feature except for the last one, which enabled solari when I ran the
solari example.
## MipmapFilterMode is split from FilterMode
- Split MipmapFilterMode from FilterMode #8314:
https://github.com/gfx-rs/wgpu/pull/8314
solution: implement From for `MipmapFilterMode`/`ImageFilterMode` since
the values are the same. The split was because the spec indicates they
are different types, even though they have the same values.
## Push Constants are now Immediates
- https://github.com/gfx-rs/wgpu/pull/8724
immediate_size is [a
u32](https://docs.rs/wgpu/28.0.0/wgpu/struct.PipelineLayoutDescriptor.html#structfield.immediate_size)
so use that instead of `PushConstantRange`
## Capabilities name changes
- https://github.com/gfx-rs/wgpu/pull/8671
Got new list from
https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/device/mod.rs#L449
and copied it in.
## subgroup_{min,max}_size moved from Limits to AdapterInfo
- https://github.com/gfx-rs/wgpu/pull/8609
Update the limits to have the fields they have now, mirror the logic
from the other limits calls.
## multiview_mask
- https://github.com/gfx-rs/wgpu/pull/8206
set to None because we don't use it currently. Its vaguely for VR.
## error scope is now a guard
- https://github.com/gfx-rs/wgpu/pull/8685
retain guard and then pop() it later
---
I made one mistake during the PR, thinking set_immediates was going to
be the size of the immediates and not the offset. I'd like reviewers to
take a look at immediates offset and size sites specifically just in
case I missed something.
Here's a bunch of examples running
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 47
22@2x"
src="https://github.com/user-attachments/assets/83dcf4c8-69f5-480a-b724-86598530f25a"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 48
44@2x"
src="https://github.com/user-attachments/assets/46d897fa-1ab2-44ef-8055-fe2fce740dbc"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
10@2x"
src="https://github.com/user-attachments/assets/6ae7a9bf-0473-4800-8dfc-233a6a41d6df"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
31@2x"
src="https://github.com/user-attachments/assets/89f84a26-cfbd-4196-bca8-111c3d20ba7b"
/>
## Known Issues
> [!NOTE]
>
> There are no current known issues. Everything previous has been
solved.
- [x] enable extensions can not be written in naga oil in a way that
allows them to be used in composed modules.
Update: this was fixed by introducing a flag in naga-oil to force
shaders to allow ray queries in composed modules when using bevy_solari.
This is temporary and will be different in WESL-future.
<details><summary>old explanation</summary>
This is blocking solari from working on nvidia (solari runs successfully
on macos m1) because it needs `enable wgpu_ray_query;`. Putting the
declaration before `#define_import_path` means it gets stripped out
(afaict), and putting it after results in
```
error: expected global declaration, but found a global directive
┌─ embedded://bevy_solari/scene/raytracing_scene_bindings.wgsl:3:1
│
3 │ enable wgpu_ray_query;
│ ^^^^^^ written after first global declaration
│
= expected global declaration, but found a global directive
```
</details>
- [x] dlss_wgpu mixes apis which [causes panics
now](https://github.com/bevyengine/dlss_wgpu/pull/17#issuecomment-3690847524).
<details><summary>Previous notes as dlss_wgpu was being fixed
here</summary>
The wgpu release notes don't mention which PR this was introduced in,
only saying:
> Using both the wgpu command encoding APIs and
CommandEncoder::as_hal_mut on the same encoder will now result in a
panic.
It was caused by https://github.com/gfx-rs/wgpu/pull/8373 which claimed
to not know of any use cases
> With record on finish, the actual ordering on the command buffer is
deeply counter intuitive (all as_hal would come first) and I think it
additionally was just flat out broken in some ways
> -
https://discord.com/channels/691052431525675048/743663924229963868/1453786307099758683
Possible path forward is using multiple command buffers:
https://discord.com/channels/691052431525675048/743663924229963868/1453795633503670415
</summary>
---------
Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
# Objective
Fixes#22571
## Solution
Added `FpsOverlaySystems` system set and explicitly ordered
`customize_overlay` to run before `update_text`. This gets rid of the
internal ambiguity warnings and also gives users a way to order their
own systems against the overlay.
## Testing
Ran locally with ambiguity warnings enabled - no more internal overlay
warnings. Didn't add a unit test since scheduling order is tricky to
test in isolation.
To verify:
- Enable `ScheduleBuildSettings` ambiguity warnings.
- Add a user system that uses `TextUiWriter`.
- Run an app with `FpsOverlayPlugin` and confirm no overlay-related
ambiguity warnings.
With #22603 landed, all known issues that could cause Bevy to cull
meshes that shouldn't have been culled are fixed, so there now seems to
be consensus that we can remove occlusion culling from the
`experimental` namespace. This patch does that (and in fact removes the
`experimental` module from `bevy_render` entirely, as it's now empty).
The original name is inaccurate since you can provide whatever usages
you want. As we make the renderer more modular and flexible, especially
if we develop a compute abstraction, having an easy way to bind things
like vertex buffers could be desirable.
I'd *really* like to just call this `Buffer` to keep it short and sweet,
but I know that proved controversial in the original PR.
Bump version after release
This PR has been auto-generated
---------
Co-authored-by: Bevy Auto Releaser <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: François Mockers <francois.mockers@vleue.com>
## Summary
Derives `Reflect` on `FpsOverlayConfig` and `FrameTimeGraphConfig` to
enable runtime reflection capabilities for these configuration structs.
For example, allows modifying the config in bevy inspector egui.
## Changes
- Added `Reflect` derive to `FpsOverlayConfig` with
`#[reflect(Resource)]` attribute
- Added `Reflect` derive to `FrameTimeGraphConfig` (required since it's
a field in `FpsOverlayConfig`)
- Added `use bevy_reflect::Reflect;` import
# Objective
- Followup on #21237
- It can be hard to share how to record a demo for a specific feature
- Make it easy
## Solution
- Add a dev plugin that can move the camera
- Add plumbing to CI testing to be able to move the camera and control
screen recording
- Demo can be configured in code or in a configuration file
## Testing
- Add to an example:
```rs
let fps = 120; // FPS for the example on your computer
[...]
// Before `DefaultPlugins`:
.insert_resource(CiTestingConfig {
events: vec![
CiTestingEventOnFrame(fps * 1, ci_testing::CiTestingEvent::StartScreenRecording),
{
let transform = Transform::from_xyz(0.7, 0.7, -1.0)
.looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y);
CiTestingEventOnFrame(
fps * 6,
ci_testing::CiTestingEvent::MoveCamera {
translation: transform.translation,
rotation: transform.rotation,
},
)
},
{
let transform = Transform::from_xyz(-0.7, 0.7, -1.0)
.looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y);
CiTestingEventOnFrame(
fps * 11,
ci_testing::CiTestingEvent::MoveCamera {
translation: transform.translation,
rotation: transform.rotation,
},
)
},
{
let transform = Transform::from_xyz(-0.7, 0.7, 1.0)
.looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y);
CiTestingEventOnFrame(
fps * 16,
ci_testing::CiTestingEvent::MoveCamera {
translation: transform.translation,
rotation: transform.rotation,
},
)
},
{
let transform = Transform::from_xyz(0.7, 0.7, 1.0)
.looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y);
CiTestingEventOnFrame(
fps * 21,
ci_testing::CiTestingEvent::MoveCamera {
translation: transform.translation,
rotation: transform.rotation,
},
)
},
CiTestingEventOnFrame(fps * 26, ci_testing::CiTestingEvent::StopScreenRecording),
],
..default()
})
```
- Run the example with `--features
bevy_internal/screenrecording,bevy_ci_testing`
- Lay back, enjoy your demo recording
---
## Showcase
https://github.com/user-attachments/assets/bbd9e56d-58c1-41eb-b6b4-1f1db2f2dab5
# Objective
- Screen Recording is not ready to be exposed, and very hard to build on
windows
## Solution
- Disable it for now on windows
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
# Objective
- Followup on #21235
- See
https://github.com/mockersf/bevy/compare/easy-screenshots...mockersf:bevy:easy-screenrecording
for what's new
- Be able to record videos from Bevy in a consistent manner
## Solution
- Make a new `EasyScreenRecordPlugin` in the dev tools
## Testing
- Add to any example
```
.add_plugins(bevy::dev_tools::EasyScreenRecordPlugin::default())
```
- Run the example with the feature `bevy_internal/screenrecording`
enabled
- press the space bar
- wait for it...
- press the space bar again
- screen recording! 🎉
- almost... you now have a h264 file. VLC can read them, but they are
not the most friendly format
- `ffmpeg` is our friend! `for file in *.h264; do ffmpeg -i $file
$file.mp4; done`
- you now have a .mp4 file that can be shared anywhere!
---
## Showcase
directly taken by Bevy
https://github.com/user-attachments/assets/217f5093-9443-40e5-b2ce-33f65f6a56c6
# Objective
#20830 created the possibility that we may want to have render targets
that produce a number of outputs, e.g. depth and normals. This is a
first step towards something like that (e.g. a `RendersTo` relation) by
converting `RenderTarget` to be a component. This is also useful for
out-of-tree render targets that may want to do something like
`#[require(RenderTarget::Image)]` once BSN lands.
## Solution
Make it a component.
# Objective
- https://github.com/bevyengine/bevy/pull/19363 finally allows
self-state transitions
- The naming is a bit meh (`set_forced`)
- Many people expect this to work out of the box
- That PR also missed a few spots where this distinction applies
## Solution
- Expand on https://github.com/bevyengine/bevy/pull/19363 by making it
the default
- Rename `set` -> `set_if_neq`
- Rename `set_forced` -> `set`
- Add the two variants to
- commands
- reflection
- computed states
- make the transition logs a bit less chatty in the common case
- add a test for the new behavior
## Testing
- CI
# Objective
- Fixes#21362
- The FrameTimeGraph uses a material that crashes in WebGL (but not
WebGPU) even if the FrameTimeGraph is disabled. We need to prevent the
FrameTimeGraph from being created when we build for WASM.
## Solution
- If the build is for WASM with only WebGL, we skip the ceration of the
FrameTimeGraph. Additionally, if the FrameTimeGraph is enabled, we
provide a warning to inform the user that the FrameTimeGraph isn't
supported on WebGL.
## Testing
- I used the repro provided in the issue.
Updates the requirements on [ron](https://github.com/ron-rs/ron) to
permit the latest version.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/ron-rs/ron/releases">ron's
releases</a>.</em></p>
<blockquote>
<h2>v0.12.0</h2>
<h2>What's Changed</h2>
<ul>
<li>Add Serializer::into_inner method to extract the writer by <a
href="https://github.com/Thomas-Mewily"><code>@Thomas-Mewily</code></a>
in <a
href="https://redirect.github.com/ron-rs/ron/pull/588">ron-rs/ron#588</a></li>
<li>Add <code>ron-lsp</code> to README by <a
href="https://github.com/jasonjmcghee"><code>@jasonjmcghee</code></a>
in <a
href="https://redirect.github.com/ron-rs/ron/pull/589">ron-rs/ron#589</a></li>
<li>Fixed serde content detection for serde >= 1.0.220 by <a
href="https://github.com/juntyr"><code>@juntyr</code></a> in <a
href="https://redirect.github.com/ron-rs/ron/pull/582">ron-rs/ron#582</a></li>
<li>Further deprecate base64 byte strings by removing parsing support
outside the error path by <a
href="https://github.com/juntyr"><code>@juntyr</code></a> in <a
href="https://redirect.github.com/ron-rs/ron/pull/566">ron-rs/ron#566</a></li>
<li>Bump ron to v0.12.0 by <a
href="https://github.com/juntyr"><code>@juntyr</code></a> in <a
href="https://redirect.github.com/ron-rs/ron/pull/591">ron-rs/ron#591</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a
href="https://github.com/Thomas-Mewily"><code>@Thomas-Mewily</code></a>
made their first contribution in <a
href="https://redirect.github.com/ron-rs/ron/pull/588">ron-rs/ron#588</a></li>
<li><a
href="https://github.com/jasonjmcghee"><code>@jasonjmcghee</code></a>
made their first contribution in <a
href="https://redirect.github.com/ron-rs/ron/pull/589">ron-rs/ron#589</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/ron-rs/ron/compare/v0.11.0...v0.12.0">https://github.com/ron-rs/ron/compare/v0.11.0...v0.12.0</a></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/ron-rs/ron/blob/master/CHANGELOG.md">ron's
changelog</a>.</em></p>
<blockquote>
<h2>[0.12.0] - 2025-11-12</h2>
<h3>API Changes</h3>
<ul>
<li>Breaking: Removed the <code>ron::error::Error::Base64Error</code>
variant. (<a
href="https://redirect.github.com/ron-rs/ron/pull/566">#566</a>)</li>
<li>Added <code>into_inner()</code> method to
<code>ron::ser::Serializer</code> to retrieve the inner writer. (<a
href="https://redirect.github.com/ron-rs/ron/pull/588">#588</a>)</li>
<li>Removed the <code>base64</code> dependency. (<a
href="https://redirect.github.com/ron-rs/ron/pull/566">#566</a>)</li>
</ul>
<h3>Format Changes</h3>
<ul>
<li><strong>Format-Breaking:</strong> Remote base64-encoded byte strings
deserialisation, replaced by Rusty byte strings in v0.9.0 (<a
href="https://redirect.github.com/ron-rs/ron/pull/566">#566</a>)</li>
</ul>
<h3>Bug Fixes</h3>
<ul>
<li>Fixed untagged enum deserialisation for serde >= 1.0.220 with
better serde content detection (<a
href="https://redirect.github.com/ron-rs/ron/pull/582">#582</a>)</li>
</ul>
<h2>[0.11.0] - 2025-08-27</h2>
<h3>API Changes</h3>
<ul>
<li>Breaking: <code>SpannedError</code> now stores the full error span
in span: Span { start: Position, end: Position }`, to facilitate, e.g.,
language server highlighting of syntax errors.</li>
<li>Breaking: Added <code>no_std</code> support via a new
<code>std</code> feature (enabled by default). With default features
disabled, you must enable the <code>std</code> feature to access
<code>de::from_reader</code>, and the <code>std::io</code> operations on
<code>Options</code>, such as <code>from_reader</code>,
<code>from_reader_seed</code>, <code>to_io_writer</code>, and
<code>to_io_writer_pretty</code> (<a
href="https://redirect.github.com/ron-rs/ron/pull/567">#567</a>)</li>
<li>Breaking: Fixed (again) <code>ron::value::Number</code> to ensure it
is non-exhaustive, to avoid breaking <code>match</code>es when feature
unification enables more of its variants than expected (<a
href="https://redirect.github.com/ron-rs/ron/pull/568">#568</a>)</li>
</ul>
<h3>Examples</h3>
<ul>
<li>Add a new example <code>file_read_write_vec.rs</code> for reading
and writing <code>Vec<T></code> to/from files. (<a
href="https://redirect.github.com/ron-rs/ron/pull/573">#573</a>)</li>
</ul>
<h2>[0.10.1] - 2025-04-08</h2>
<h3>API Changes</h3>
<ul>
<li>Add <code>ron::Options::to_io_writer</code> and
<code>ron::Options::to_io_writer_pretty</code> to allow writing into an
<code>io::Writer</code> (<a
href="https://redirect.github.com/ron-rs/ron/pull/561">#561</a>)</li>
<li>Breaking: <code>ron::value::Number</code> is now non-exhaustive, to
avoid breaking <code>match</code>es when feature unification enables
more of its variants than expected (<a
href="https://redirect.github.com/ron-rs/ron/pull/564">#564</a>)</li>
</ul>
<h2>[0.9.0] - 2025-03-18</h2>
<h3>API Changes</h3>
<ul>
<li>Add <code>ron::value::RawValue</code> helper type which can
(de)serialize any valid RON (<a
href="https://redirect.github.com/ron-rs/ron/pull/407">#407</a>)</li>
<li>Add <code>escape_strings</code> option to <code>PrettyConfig</code>
to allow serialising with or without escaping (<a
href="https://redirect.github.com/ron-rs/ron/pull/426">#426</a>)</li>
<li>Add <code>compact_maps</code> and <code>compact_structs</code>
options to <code>PrettyConfig</code> to allow serialising maps and
structs on a single line (<a
href="https://redirect.github.com/ron-rs/ron/pull/448">#448</a>)</li>
<li>Add minimal support for <code>#[serde(flatten)]</code> with
roundtripping through RON maps (<a
href="https://redirect.github.com/ron-rs/ron/pull/455">#455</a>)</li>
<li>Add minimal roundtripping support for <code>#[serde(tag =
"tag")]</code>, <code>#[serde(tag = "tag", content =
"content")]</code>, and <code>#[serde(untagged)]</code> enums
(<a
href="https://redirect.github.com/ron-rs/ron/pull/451">#451</a>)</li>
<li>Breaking: Expand the <code>value::Number</code> enum to explicitly
encode all possible number types (<a
href="https://redirect.github.com/ron-rs/ron/pull/479">#479</a>)</li>
<li>Add <code>number_suffixes</code> option to <code>PrettyConfig</code>
to allow serialising numbers with their explicit type suffix, e.g.
<code>42i32</code> (<a
href="https://redirect.github.com/ron-rs/ron/pull/481">#481</a>)</li>
<li>Allow <code>ron::value::RawValue</code> to capture any whitespace to
the left and right of a ron value (<a
href="https://redirect.github.com/ron-rs/ron/pull/487">#487</a>)</li>
<li>Breaking: Enforce that ron always writes valid UTF-8 (<a
href="https://redirect.github.com/ron-rs/ron/pull/488">#488</a>)</li>
<li>Add convenient <code>Value::from</code> impls (<a
href="https://redirect.github.com/ron-rs/ron/pull/498">#498</a>)</li>
<li>Add new extension <code>explicit_struct_names</code> which requires
that struct names are included during deserialization (<a
href="https://redirect.github.com/ron-rs/ron/pull/522">#522</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/ron-rs/ron/commit/c6a8cff1eff986cc1ad9b026e838335187d411f0"><code>c6a8cff</code></a>
Bump ron to v0.12.0 (<a
href="https://redirect.github.com/ron-rs/ron/issues/591">#591</a>)</li>
<li><a
href="https://github.com/ron-rs/ron/commit/f2c17284b4df666437614db57f5334c963dba201"><code>f2c1728</code></a>
v0.12: Further deprecate base64 byte strings by removing parsing support
outs...</li>
<li><a
href="https://github.com/ron-rs/ron/commit/5630b0f1843b2e3cb1c856961dfc941326bd225e"><code>5630b0f</code></a>
Fixed serde content detection for serde >= 1.0.220 (<a
href="https://redirect.github.com/ron-rs/ron/issues/582">#582</a>)</li>
<li><a
href="https://github.com/ron-rs/ron/commit/3184df3d2c778cba512bcb3ae9ee4109ca7c01ea"><code>3184df3</code></a>
Add <code>ron-lsp</code> to README (<a
href="https://redirect.github.com/ron-rs/ron/issues/589">#589</a>)</li>
<li><a
href="https://github.com/ron-rs/ron/commit/9b9b88e70d64e24805fd7824192348d695480ee7"><code>9b9b88e</code></a>
Add Serializer::into_inner method to extract the writer (<a
href="https://redirect.github.com/ron-rs/ron/issues/588">#588</a>)</li>
<li>See full diff in <a
href="https://github.com/ron-rs/ron/compare/v0.11.0...v0.12.0">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective
- The `update_text()` system was running on every frame, causing
unnecessary performance overhead.
## Solution
- Refactored it to use `on_timer()` to run on a configurable interval.
## Testing
- Ran the `fps_overlay.rs` example; the overlay works correctly and the
new performance warning triggers as expected.
---
# Objective
- Same state transitions have their uses but are not currently possible
## Solution
- Add a `set_forced` method on `NextState` that will trigger `OnEnter`
and `OnExit`
- Rerun state transitions when `set_forced` has been used
- Rerun them is `set` is called *after* `set_forced` with the same state
## Objective
Fixes#21303 (but does not add any testing that similar issues will not
recur).
## Solution
Globally replace `feature(doc_auto_cfg)` with `feature(doc_cfg)`.
## Testing
Tested that `RUSTDOCFLAGS=--cfg=docsrs cargo +nightly doc -p
bevy_platform` succeeds. This is not a test of all documentation builds,
but I do not know of a way to do that until bevy’s dependencies catch
up.
Bevy Auto Releaser