Further bloom improvements #4

# Objective Fix bevyengine#6555. ## Solution Bump `gilrs` version to 0.10.

…evyengine#4927) # Objective Archetype is a deceptively large type in memory. It stores metadata about which components are in which storage in multiple locations, which is only used when creating new Archetypes while moving entities. ## Solution Remove the redundant `Box<[ComponentId]>`s and iterate over the sparse set of component metadata instead. Reduces Archetype's size by 4 usizes (32 bytes on 64-bit systems), as well as the additional allocations for holding these slices. It'd seem like there's a downside that the origin archetype has it's component metadata iterated over twice when creating a new archetype, but this change also removes the extra `Vec<ArchetypeComponentId>` allocations when creating a new archetype which may amortize out to a net gain here. This change likely negatively impacts creating new archetypes with a large number of components, but that's a cost mitigated by the fact that these archetypal relationships are cached in Edges and is incurred only once for each edge created. ## Additional Context There are several other in-flight PRs that shrink Archetype: - bevyengine#4800 merges the entities and rows Vecs together (shaves off 24 bytes per archetype) - bevyengine#4809 removes unique_components and moves it to it's own dedicated storage (shaves off 72 bytes per archetype) --- ## Changelog Changed: `Archetype::table_components` and `Archetype::sparse_set_components` return iterators instead of slices. `Archetype::new` requires iterators instead of parallel slices/vecs. ## Migration Guide Do I still need to do this? I really hope people were not relying on the public facing APIs changed here.

# Objective Make core types in ECS smaller. The column sparse set in Tables is never updated after creation. ## Solution Create `ImmutableSparseSet` which removes the capacity fields in the backing vec's and the APIs for inserting or removing elements. Drops the size of the sparse set by 3 usizes (24 bytes on 64-bit systems) ## Followup ~~After bevyengine#4809, Archetype's component SparseSet should be replaced with it.~~ This has been done. --- ## Changelog Removed: `Table::component_capacity` ## Migration Guide `Table::component_capacity()` has been removed as Tables do not support adding/removing columns after construction. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

# Objective * Enable `Res` and `Query` parameter mutual exclusion * Required for bevyengine#5080 The `FilteredAccessSet::get_conflicts` methods didn't work properly with `Res` and `ResMut` parameters. Because those added their access by using the `combined_access_mut` method and directly modifying the global access state of the FilteredAccessSet. This caused an inconsistency, because get_conflicts assumes that ALL added access have a corresponding `FilteredAccess` added to the `filtered_accesses` field. In practice, that means that SystemParam that adds their access through the `Access` returned by `combined_access_mut` and the ones that add their access using the `add` method lived in two different universes. As a result, they could never be mutually exclusive. ## Solution This commit fixes it by removing the `combined_access_mut` method. This ensures that the `combined_access` field of FilteredAccessSet is always updated consistently with the addition of a filter. When checking for filtered access, it is now possible to account for `Res` and `ResMut` invalid access. This is currently not needed, but might be in the future. We add the `add_unfiltered_{read,write}` methods to replace previous usages of `combined_access_mut`. We also add improved Debug implementations on FixedBitSet so that their meaning is much clearer in debug output. --- ## Changelog * Fix `Res` and `Query` parameter never being mutually exclusive. ## Migration Guide Note: this mostly changes ECS internals, but since the API is public, it is technically breaking: * Removed `FilteredAccessSet::combined_access_mut` * Replace _immutable_ usage of those by `combined_access` * For _mutable_ usages, use the new `add_unfiltered_{read,write}` methods instead of `combined_access_mut` followed by `add_{read,write}`

…#4853) # Objective BlobVec currently relies on a scratch piece of memory allocated at initialization to make a temporary copy of a component when using `swap_remove_and_{forget/drop}`. This is potentially suboptimal as it writes to a, well-known, but random part of memory instead of using the stack. ## Solution As the `FIXME` in the file states, replace `swap_scratch` with a call to `swap_nonoverlapping::<u8>`. The swapped last entry is returned as a `OwnedPtr`. In theory, this should be faster as the temporary swap is allocated on the stack, `swap_nonoverlapping` allows for easier vectorization for bigger types, and the same memory is used between the swap and the returned `OwnedPtr`.

# Objective - The `contributors` example panics when attempting to generate an empty range if the window height is smaller than the sprites - Don't do that ## Solution - Clamp the bounce height to be 0 minimum, and generate an inclusive range when passing it to `rng.gen_range`

When I was upgrading to 0.9 noticed there were some changes to the timer, mainly the `TimerMode`. When switching from the old `is_repeating()` and `set_repeating()` to the new `mode()` and `set_mode()` noticed the docs still had the old description.

# Objective - Fix a panic in wasm when using globals in a shader ## Solution - Similar to bevyengine#6460

# Objective Fixes bevyengine#6661 ## Solution Make `SceneSpawner::spawn_dynamic` return `InstanceId` like other functions there. --- ## Changelog Make `SceneSpawner::spawn_dynamic` return `InstanceId` instead of `()`.

# Objective Delete `ImageMode`. It doesn't do anything except mislead people into thinking it controls the aspect ratio of images somehow. Fixes bevyengine#3933 and bevyengine#6637 ## Solution Delete `ImageMode` ## Changelog Removes the `ImageMode` enum. Removes the `image_mode` field from `ImageBundle` Removes the `With<ImageMode>` query filter from `image_node_system` Renames `image_node_system` to` update_image_calculated_size_system`

@page

# Objective structs containing wgpu types take a long time to compile. this is particularly bad for generics containing the wgpu structs (like the depth pipeline builder with `#[derive(SystemParam)]` i've been working on). we can avoid that by boxing and type-erasing in the bevy `render_resource` wrappers. type system magic is not a strength of mine so i guess there will be a cleaner way to achieve this, happy to take feedback or for it to be taken as a proof of concept if someone else wants to do a better job. ## Solution - add macros to box and type-erase in debug mode - leave current impl for release mode timings: <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta name=ProgId content=Excel.Sheet> <meta name=Generator content="Microsoft Excel 15"> <link id=Main-File rel=Main-File href="file:///C:/Users/robfm/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> <link rel=File-List href="file:///C:/Users/robfm/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">  </head> <body link="#0563C1" vlink="#954F72"> current | | | -- | -- | -- | -- | Total time: | 64.9s | | bevy_pbr v0.9.0-dev | 19.2s | | bevy_render v0.9.0-dev | 17.0s | | bevy_sprite v0.9.0-dev | 15.1s | | DepthPipelineBuilder | 18.7s | | | | with type-erasing | | | diff | Total time: | 49.0s | -24% | bevy_render v0.9.0-dev | 12.0s | -38% | bevy_pbr v0.9.0-dev | 8.7s | -49% | bevy_sprite v0.9.0-dev | 6.1s | -60% | DepthPipelineBuilder | 1.2s | -94% </body> </html> the depth pipeline builder is a binary with body: ```rust use std::{marker::PhantomData, hash::Hash}; use bevy::{prelude::*, ecs::system::SystemParam, pbr::{RenderMaterials, MaterialPipeline, ShadowPipeline}, render::{renderer::RenderDevice, render_resource::{SpecializedMeshPipelines, PipelineCache}, render_asset::RenderAssets}}; fn main() { println!("Hello, world p!\n"); } #[derive(SystemParam)] pub struct DepthPipelineBuilder<'w, 's, M: Material> where M::Data: Eq + Hash + Clone, { render_device: Res<'w, RenderDevice>, material_pipeline: Res<'w, MaterialPipeline<M>>, material_pipelines: ResMut<'w, SpecializedMeshPipelines<MaterialPipeline<M>>>, shadow_pipeline: Res<'w, ShadowPipeline>, pipeline_cache: ResMut<'w, PipelineCache>, render_meshes: Res<'w, RenderAssets<Mesh>>, render_materials: Res<'w, RenderMaterials<M>>, msaa: Res<'w, Msaa>, #[system_param(ignore)] _p: PhantomData<&'s M>, } ```

# Objective Fix android touch events being flipped. Only removed test for android, don't have ios device to test with. Tested with emulator and physical device. ## Solution Remove check, no longer needed with coordinate change in 0.9

# Objective Make core pipeline graphic nodes, including `BloomNode`, `FxaaNode`, `TonemappingNode` and `UpscalingNode` public. This will allow users to construct their own render graphs with these build-in nodes. ## Solution Make them public. Also put node names into bevy's core namespace (`core_2d::graph::node`, `core_3d::graph::node`) which makes them consistent.

…er (bevyengine#5214) # Objective Fix bevyengine#5149 ## Solution Instead of returning the **total count** of elements in the `QueryIter` in `size_hint`, we return the **count of remaining elements**. This Fixes bevyengine#5149 even when bevyengine#5148 gets merged. - bevyengine#5149 - bevyengine#5148 --- ## Changelog - Fix partially consumed `QueryIter` and `QueryCombinationIter` having invalid `size_hint` Co-authored-by: Nicola Papale <nicopap@users.noreply.github.com>

# Objective Fix bevyengine#6453. ## Solution Use the solution mentioned in the issue by catching the unwind and dropping the error. Wrap the `executor.try_tick` calls with `std::catch::unwind`. Ideally this would be moved outside of the hot loop, but the mut ref to the `spawned` future is not `UnwindSafe`. This PR only addresses the bug, we can address the perf issues (should there be any) later.

# Objective Fixes bevyengine#4884. `ComponentTicks` stores both added and changed ticks contiguously in the same 8 bytes. This is convenient when passing around both together, but causes half the bytes fetched from memory for the purposes of change detection to effectively go unused. This is inefficient when most queries (no filter, mutating *something*) only write out to the changed ticks. ## Solution Split the storage for change detection ticks into two separate `Vec`s inside `Column`. Fetch only what is needed during iteration. This also potentially also removes one blocker from autovectorization of dense queries. EDIT: This is confirmed to enable autovectorization of dense queries in `for_each` and `par_for_each` where possible. Unfortunately `iter` has other blockers that prevent it. ### TODO - [x] Microbenchmark - [x] Check if this allows query iteration to autovectorize simple loops. - [x] Clean up all of the spurious tuples now littered throughout the API ### Open Questions - ~~Is `Mut::is_added` absolutely necessary? Can we not just use `Added` or `ChangeTrackers`?~~ It's optimized out if unused. - ~~Does the fetch of the added ticks get optimized out if not used?~~ Yes it is. --- ## Changelog Added: `Tick`, a wrapper around a single change detection tick. Added: `Column::get_added_ticks` Added: `Column::get_column_ticks` Added: `SparseSet::get_added_ticks` Added: `SparseSet::get_column_ticks` Changed: `Column` now stores added and changed ticks separately internally. Changed: Most APIs returning `&UnsafeCell<ComponentTicks>` now returns `TickCells` instead, which contains two separate `&UnsafeCell<Tick>` for either component ticks. Changed: `Query::for_each(_mut)`, `Query::par_for_each(_mut)` will now leverage autovectorization to speed up query iteration where possible. ## Migration Guide TODO

# Objective - Bevy should be usable to create 'overlay' type apps, where the input is not captured by Bevy, but passed down/into a target app, or to allow passive displays/widgets etc. ## Solution - the `winit::window::Window` already has a `set_cursor_hittest()` which basically does this for mouse input events, so I've exposed it (trying to copy the style laid out in the existing wrappings, and added a simple demo. --- ## Changelog - Added `hittest` to `WindowAttributes` - Added the `hittest`'s setters/getters - Modified the `WindowBuilder` - Modifed the `WindowDescriptor`'s `Default` impl. - Added an example `cargo run --example fallthrough`

@rezural

# Objective This add a ctor to `Box` to aid the creation of non-centred boxes. The PR adopts @rezural's work on PR bevyengine#3322, taking into account the feedback on that PR from @james7132. ## Solution `Box::from_corners()` creates a `Box` from two opposing corners and automatically determines the min and max extents to ensure that the `Box` is well-formed. Co-authored-by: rezural <rezural@protonmail.com>

…ngine#6676) # Objective Latest Release, "bevy 0.9" move the FrameCount updater into RenderPlugin, it leads to user who only run app with Core/Minimal Plugin cannot get the right number of FrameCount, it always return 0. As for use cases like a server app, we don't want to add render dependencies to the app. More detail in bevyengine#6656 ## Solution - Move the `update_frame_count` into CorePlugin

Add a method to rotate a transform to point towards a direction. Also updated the docs to link to `forward` and `up` instead of mentioning local negative `Z` and local `Y`. Unfortunately, links to methods don't work in rust-analyzer :( Co-authored-by: Devil Ira <justthecooldude@gmail.com>

# Objective Allow more use cases where the user may benefit from both `ExtractComponentPlugin` _and_ `UniformComponentPlugin`. ## Solution Add an associated type to `ExtractComponent` in order to allow specifying the output component (or bundle). Make `extract_component` return an `Option<_>` such that components can be extracted only when needed. What problem does this solve? `ExtractComponentPlugin` allows extracting components, but currently the output type is the same as the input. This means that use cases such as having a settings struct which turns into a uniform is awkward. For example we might have: ```rust struct MyStruct { enabled: bool, val: f32 } struct MyStructUniform { val: f32 } ``` With the new approach, we can extract `MyStruct` only when it is enabled, and turn it into its related uniform. This chains well with `UniformComponentPlugin`. The user may then: ```rust app.add_plugin(ExtractComponentPlugin::<MyStruct>::default()); app.add_plugin(UniformComponentPlugin::<MyStructUniform>::default()); ``` This then saves the user a fair amount of boilerplate. ## Changelog ### Changed - `ExtractComponent` can specify output type, and outputting is optional. Co-authored-by: Torstein Grindvik <52322338+torsteingrindvik@users.noreply.github.com>

Without this fix, piped systems containing exclusive systems fail to run, giving a runtime panic. With this PR, running piped systems that contain exclusive systems now works. ## Explanation of the bug This is because, unless overridden, the default implementation of `run` from the `System` trait simply calls `run_unsafe`. That is not valid for exclusive systems. They must always be called via `run`, as `run_unsafe` takes `&World` instead of `&mut World`. Trivial reproduction example: ```rust fn main() { App::new() .add_plugins(DefaultPlugins) .add_system(exclusive.pipe(another)) .run(); } fn exclusive(_world: &mut World) {} fn another() {} ``` If you run this, you will get a panic 'Cannot run exclusive systems with a shared World reference' and the backtrace shows how bevy (correctly) tries to call the `run` method (because the system is exclusive), but it is the implementation from the `System` trait (because `PipeSystem` does not have its own), which calls `run_unsafe` (incorrect): - 3: <bevy_ecs::system::system_piping::PipeSystem<SystemA,SystemB> as bevy_ecs::system::system::System>::run_unsafe - 4: bevy_ecs::system::system::System::run

# Objective Fixes bevyengine#6498. ## Solution Adding a parent node with properties AlignItems::Center and JustifyContent::Center to centered child nodes and removing their auto-margin properties.

# Objective Fixes bevyengine#4697. Hierarchical propagation of properties, currently only Transform -> GlobalTransform, can be a very expensive operation. Transform propagation is a strict dependency for anything positioned in world-space. In large worlds, this can take quite a bit of time, so limiting it to a single thread can result in poor CPU utilization as it bottlenecks the rest of the frame's systems. ## Solution - Move transforms without a parent or a child (free-floating (Global)Transform) entities into a separate parallel system. - Chunk the hierarchy based on the root entities and process it in parallel with `Query::par_for_each_mut`. - Utilize the hierarchy's specific properties introduced in bevyengine#4717 to allow for safe use of `Query::get_unchecked` on multiple threads. Assuming each child is unique in the hierarchy, it is impossible to have an aliased `&mut GlobalTransform` so long as we verify that the parent for a child is the same one propagated from. --- ## Changelog Removed: `transform_propagate_system` is no longer `pub`.

# Objective - Fix dead links on this docs page: https://docs.rs/bevy/0.9.0/bevy/struct.DefaultPlugins.html ## Solution - Point links to the imported versions instead of the versions in external crates.

# Objective `add_node_edge` and `add_slot_edge` are fallible methods, but are always used with `.unwrap()`. `input_node` is often unwrapped as well. This points to having an infallible behaviour as default, with an alternative fallible variant if needed. Improves readability and ergonomics. ## Solution - Change `add_node_edge` and `add_slot_edge` to panic on error. - Change `input_node` to panic on `None`. - Add `try_add_node_edge` and `try_add_slot_edge` in case fallible methods are needed. - Add `get_input_node` to still be able to get an `Option`. --- ## Changelog ### Added - `try_add_node_edge` - `try_add_slot_edge` - `get_input_node` ### Changed - `add_node_edge` is now infallible (panics on error) - `add_slot_edge` is now infallible (panics on error) - `input_node` now panics on `None` ## Migration Guide Remove `.unwrap()` from `add_node_edge` and `add_slot_edge`. For cases where the error was handled, use `try_add_node_edge` and `try_add_slot_edge` instead. Remove `.unwrap()` from `input_node`. For cases where the option was handled, use `get_input_node` instead. Co-authored-by: Torstein Grindvik <52322338+torsteingrindvik@users.noreply.github.com>

# Objective - shaders defs can now have a `bool` or `int` value - `#if SHADER_DEF <operator> 3` - ok if `SHADER_DEF` is defined, has the correct type and pass the comparison - `==`, `!=`, `>=`, `>`, `<`, `<=` supported - `#SHADER_DEF` or `#{SHADER_DEF}` - will be replaced by the value in the shader code --- ## Migration Guide - replace `shader_defs.push(String::from("NAME"));` by `shader_defs.push("NAME".into());` - if you used shader def `NO_STORAGE_BUFFERS_SUPPORT`, check how `AVAILABLE_STORAGE_BUFFER_BINDINGS` is now used in Bevy default shaders

…orrowed (bevyengine#6639) # Objective Consider the test ```rust let cell = world.cell(); let _value_a = cell.resource_mut::<A>(); let _value_b = cell.resource_mut::<A>(); ``` Currently, this will roughly execute ```rust // first call let value = unsafe { self.world .get_non_send_unchecked_mut_with_id(component_id)? }; return Some(WorldBorrowMut::new(value, archetype_component_id, self.access))) // second call let value = unsafe { self.world .get_non_send_unchecked_mut_with_id(component_id)? }; return Some(WorldBorrowMut::new(value, archetype_component_id, self.access))) ``` where `WorldBorrowMut::new` will panic if the resource is already borrowed. This means, that `_value_a` will be created, the access checked (OK), then `value_b` will be created, and the access checked (`panic`). For a moment, both `_value_a` and `_value_b` existed as `&mut T` to the same location, which is insta-UB as far as I understand it. ## Solution Flip the order so that `WorldBorrowMut::new` first checks the access, _then_ fetches creates the value. To do that, we pass a `impl FnOnce() -> Mut<T>` instead of the `Mut<T>` directly: ```rust let get_value = || unsafe { self.world .get_non_send_unchecked_mut_with_id(component_id)? }; return Some(WorldBorrowMut::new(get_value, archetype_component_id, self.access))) ```

…ne#6707) # Objective - Fixes bevyengine#6706 Zoom in on the shadow in the following images: ## Current bevy/main ### HDR On - correct ![current-hdron](https://user-images.githubusercontent.com/2632925/202943151-ecad3cbe-a76e-46df-bac9-9e590a31a9f3.png) ### HDR Off - incorrect ![current-hdroff](https://user-images.githubusercontent.com/2632925/202943154-34e3f527-a00e-4546-931d-0691204cc6a4.png) ## This PR ### HDR On - correct ![new-hdron](https://user-images.githubusercontent.com/2632925/202943383-081990de-9a14-45bd-ac52-febcc4289079.png) ### HDR Off - corrected ![new-hdroff](https://user-images.githubusercontent.com/2632925/202943388-a3b05d79-a0f3-4b1e-b114-0a9f03efe351.png) ## Close-up comparison ### New ![Screenshot from 2022-11-20 17-46-46](https://user-images.githubusercontent.com/2632925/202943552-d45c3a48-841e-47a6-981f-776c5a9563f6.png) ### Old ![Screenshot from 2022-11-20 17-46-41](https://user-images.githubusercontent.com/2632925/202943562-555cb5a2-2b20-45f9-b250-89f2bc87af5f.png) ## Solution - It turns out there was an outright missing sRGB conversion for dithering non-HDR cameras. - I also tried using a precise sRGB conversion, but it had no apparent effect on the final image. --- ## Changelog - Fix deband dithering intensity for non-HDR pipelines.

Continuation of bevyengine#6107 Co-authored-by: devil-ira <justthecooldude@gmail.com>

…bevyengine#6722) # Objective Fixes bevyengine#6713 Binary deserialization is failing for unit structs as well as structs with all ignored/skipped fields. ## Solution Add a check for the number of possible fields in a struct before deserializing. If empty, don't attempt to deserialize any fields (as there will be none). Note: ~~This does not apply to enums as they do not properly handle skipped fields (see bevyengine#6721).~~ Enums still do not properly handle skipped fields, but I decided to include the logic for it anyways to account for `#[reflect(ignore)]`'d fields in the meantime. --- ## Changelog - Fix bug where deserializing unit structs would fail for non-self-describing formats

…#6727) # Objective Remove an obscure and inconsistent bit of API. Simplify the `WorldChildBuilder` code. No idea why this even exists. An example of the removed API: ```rust world.spawn_empty().with_children(|parent| { parent.spawn_empty(); parent.push_children(&[some_entity]); // Does *not* add children to the parent. // It's actually identical to: parent.spawn_empty().push_children(&[some_entity]); }); world.spawn_empty().with_children(|parent| { // This just panics. parent.push_children(&[some_entity]); }); ``` This exists only on `WorldChildBuilder`; `ChildBuilder` does not have this API. Yeet. ## Migration Guide Hierarchy editing methods such as `with_children` and `push_children` have been removed from `WorldChildBuilder`. You can edit the hierarchy via `EntityMut` instead. Co-authored-by: devil-ira <justthecooldude@gmail.com>

…#6730) # Objective - Reverts bevyengine#5730. - Fixes bevyengine#6173, fixes bevyengine#6596. ## Solution Remove the warning entirely. ## Changelog You will no longer be spammed about > Missed 31 `bevy_input::mouse::MouseMotion` events. Consider reading from the `EventReader` more often (generally the best solution) or calling Events::update() less frequently (normally this is called once per frame). This problem is most likely due to run criteria/fixed timesteps or consuming events conditionally. See the Events documentation for more information. when you miss events. These warnings were often (but not always) a false positive. You can still check this manually by using `ManualEventReader::missed_events`

# Objective - Fixes bevyengine#6603 ## Solution - `Task`s will cancel when dropped, but wait until they return Pending before they actually get canceled. That means that if a task panics, it's possible for that error to get propagated to the scope and the scope gets dropped, while scoped tasks in other threads are still running. This is a big problem since scoped task can hold life-timed values that are dropped as the scope is dropped leading to UB. --- ## Changelog - changed `Scope` to use `FallibleTask` and await the cancellation of all remaining tasks when it's dropped.

…yengine#6725) # Objective Many types in `bevy_render` implemented `Reflect` but were not registered. ## Solution Register all types in `bevy_render` that impl `Reflect`. This also registers additional dependent types (i.e. field types). > Note: Adding these dependent types would not be needed using something like bevyengine#5781 😉 --- ## Changelog - Register missing `bevy_render` types in the `TypeRegistry`: - `camera::RenderTarget` - `globals::GlobalsUniform` - `texture::Image` - `view::ComputedVisibility` - `view::Visibility` - `view::VisibleEntities` - Register additional dependent types: - `view::ComputedVisibilityFlags` - `Vec<Entity>`

# Objective - Fix CI issue with updated `cargo-app` ## Solution - Move the Android example to its own package. It's not necessary for the CI fix, but it's cleaner, mimic the iOS example, and easier to reuse for someone wanting to setup android support in their project - Build the package in CI instead of the example The Android example is still working on my android device with this change 👍

…strations from most glam types (bevyengine#6580) # Objective > Part of bevyengine#6573 When serializing a `DynamicScene` we end up treating almost all non-value types as though their type data doesn't exist. This is because when creating the `DynamicScene` we call `Reflect::clone_value` on the components, which generates a Dynamic type for all non-value types. What this means is that the `glam` types are treated as though their `ReflectSerialize` registrations don't exist. However, the deserializer _does_ pick up the registration and attempts to use that instead. This results in the deserializer trying to operate on "malformed" data, causing this error: ``` WARN bevy_asset::asset_server: encountered an error while loading an asset: Expected float ``` ## Solution Ideally, we should better handle the serialization of possibly-Dynamic types. However, this runs into issues where the `ReflectSerialize` expects the concrete type and not a Dynamic representation, resulting in a panic: https://github.com/bevyengine/bevy/blob/0aa4147af6d583c707863484d6a8ad50ed0ed984/crates/bevy_reflect/src/type_registry.rs#L402-L413 Since glam types are so heavily used in Bevy (specifically in `Transform` and `GlobalTransform`), it makes sense to just a quick fix in that enables them to be used properly in scenes while a proper solution is found. This PR simply removes all `ReflectSerialize` and `ReflectDeserialize` registrations from the glam types that are reflected as structs. --- ## Changelog - Remove `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types ## Migration Guide This PR removes `ReflectSerialize` and `ReflectDeserialize` registrations from most glam types. This means any code relying on either of those type data existing for those glam types will need to not do that. This also means that some serialized glam types will need to be updated. For example, here is `Affine3A`: ```rust // BEFORE ( "glam::f32::affine3a::Affine3A": (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0), // AFTER "glam::f32::affine3a::Affine3A": ( matrix3: ( x_axis: ( x: 1.0, y: 0.0, z: 0.0, ), y_axis: ( x: 0.0, y: 1.0, z: 0.0, ), z_axis: ( x: 0.0, y: 0.0, z: 1.0, ), ), translation: ( x: 0.0, y: 0.0, z: 0.0, ), ) ) ```

…e#6673) # Objective Fixes bevyengine#6642 In a way that doesn't create any breaking changes, as a possible way to fix the above in a patch release. ## Solution Don't actually remove font atlases when `max_font_atlases` is exceeded. Add a warning instead. Keep `TextError::ExceedMaxTextAtlases` and `TextSettings` as-is so we don't break anything. This is a bit of a cop-out, but the problems revealed by bevyengine#6642 seem very challenging to fix properly. Maybe follow up later with something more like https://github.com/rparrett/bevy/commits/remove-max-font-atlases later, if this is the direction we want to go. ## Note See previous attempt at a "simple fix" that only solved some of the issues: bevyengine#6666

# Objective Fixes bevyengine#6739 ## Solution Implement the required traits. They cannot be implemented for `Path` directly, since it is a dynamically-sized type.

…error (bevyengine#6599) # Objective - Closes bevyengine#6590 - The grab mode is platform dependent, this is problematic for bevy users since we can't easily use the recommended way to detect if the feature works like the winit docs recommend https://docs.rs/winit/0.27.5/winit/window/struct.Window.html#method.set_cursor_grab ## Solution Try to use the grab mode that was requested, if it fails use the other one. Only then log an error if it fails after this step.

# Objective - Fix a small typo ## Solution - Type them correctly :D

# Objective - `PathBuf` and `OsString` not reflected correctly. ## Solution - Add missing registrations. - Add FromReflect impls. - Always implement `Reflect` for `OsString` just skip `Serialize` and `Deserialize` for unsupported platforms. --- ## Changelog ## Fixed - Fix reflection for `PathBuf` and `OsString`.

…#6701) # Objective - Reduce confusion around uniform bindings in materials. I've seen multiple people on discord get confused by it because it uses a struct that is named the same in the rust code and the wgsl code, but doesn't contain the same data. Also, the only reason this works is mostly by chance because the memory happens to align correctly. ## Solution - Remove the confusing parts of the doc ## Notes It's not super clear in the diff why this causes confusion, but essentially, the rust code defines a `CustomMaterial` struct with a color and a texture, but in the wgsl code the struct with the same name only contains the color. People are confused by it because the struct in wgsl doesn't need to be there. You _can_ have complex structs on each side and the macro will even combine it for you if you reuse a binding index, but as it is now, this example seems to confuse more than help people.

# Objective When a global tracing subscriber has already been set, `LogPlugin` panics with an error message explaining this. However, if a global logger has already been set, it simply panics on an unwrap. bevyengine#6426 mentiones the panic and has been fixed by unique plugins, but the panic can still occur if a logger has been set through different means or multiple apps are created, as in bevyengine#4934. The solution to that specific case isn't clear; this PR only fixes the missing error message. ## Solution - ~add error message to panic~ - turn into warning

# Objective One of the use-cases for the function `Entity::from_raw` is creating placeholder entity ids, which are meant to be overwritten later. If we use a constant for this instead of `from_raw`, it is more ergonomic and self-documenting. ## Solution Add a constant that returns an entity ID with an index of `u32::MAX` and a generation of zero. Users are instructed to overwrite this value before using it.

# Objective * Fix bevyengine#6668 * There is no need to panic when a parenting operation is redundant, as no invalid state is entered. ## Solution Make `push_children` idempotent.

…6764) # Objective * Fix bevyengine#6307 ## Solution * Rewrite the safety comment to reflect the actual invariants being asserted.

# Objective - The documentation describing different ways to spawn an Entity is missing reference to "method" for "Spawn an entity with components". ## Solution - Update the documentation to add the reference to `World::spawn`.

# Objective Document `bevy_ecs::archetype` and and declutter the public documentation for the module by making types non-`pub`. Addresses bevyengine#3362 for `bevy_ecs::archetype`. ## Solution - Add module level documentation. - Add type and API level documentation for all public facing types. - Make `ArchetypeId`, `ArchetypeGeneration`, and `ArchetypeComponentId` truly opaque IDs that are not publicly constructable. - Make `AddBundle` non-pub, make `Edges::get_add_bundle` return a `Option<ArchetypeId>` and fork the existing function into `Edges::get_add_bundle_internal`. - Remove `pub(crate)` on fields that have a corresponding pub accessor function. - Removed the `Archetypes: Default` impl, opting for a `pub(crate) fn new` alternative instead. --- ## Changelog Added: `ArchetypeGeneration` now implements `Ord` and `PartialOrd`. Removed: `Archetypes`'s `Default` implementation. Removed: `Archetype::new` and `Archetype::is_empty`. Removed: `ArchetypeId::new` and `ArchetypeId::value`. Removed: `ArchetypeGeneration::value` Removed: `ArchetypeIdentity`. Removed: `ArchetypeComponentId::new` and `ArchetypeComponentId::value`. Removed: `AddBundle`. `Edges::get_add_bundle` now returns `Option<ArchetypeId>`

# Objective - Every usage of `DrawFunctionsInternals::get_id()` was followed by a `.unwrap()`. which just adds boilerplate. ## Solution - Introduce a fallible version of `DrawFunctionsInternals::get_id()` and use it where possible. - I also took the opportunity to improve the error message a little in the case where it fails. --- ## Changelog - Added `DrawFunctionsInternals::id()`

When running Bevy on Gentoo using an AMD Radeon GPU, it panics unless `amdgpu-pro-vulkan` has been installed (and it took quite a bit of experimentation to find this information). This PR adds a mention of this to the linux dependencies documentation.

# Objective - Support textures in `Rgb9e5Ufloat` format. ## Solution - Add `TextureFormatPixelInfo` for `Rgb9e5Ufloat`. Tested this with a `Rgb9e5Ufloat` encoded KTX2 texture.

# Objective - fixes bevyengine#6736 ## Solution - Register `Hash` on all of glam's reflected integer vector types.

… available (bevyengine#6787) # Objective - Since bevyengine#5900 3d examples fail in wasm ``` ERROR crates/bevy_render/src/render_resource/pipeline_cache.rs:660 failed to process shader: Unknown shader def: 'AVAILABLE_STORAGE_BUFFER_BINDINGS' ``` ## Solution - Fix it by always adding the shaderdef `AVAILABLE_STORAGE_BUFFER_BINDINGS` with the actual value, instead of 3 when 3 or more were available

# Objective The soundness of the ECS `World` partially relies on the correctness of the state of `Entities` stored within it. We're currently allowing users to (unsafely) mutate it, as well as readily construct it without using a `World`. While this is not strictly unsound so long as users (including `bevy_render`) safely use the APIs, it's a fairly easy path to unsoundness without much of a guard rail. Addresses bevyengine#3362 for `bevy_ecs::entity`. Incorporates the changes from bevyengine#3985. ## Solution Remove `Entities`'s `Default` implementation and force access to the type to only be through a properly constructed `World`. Additional cleanup for other parts of `bevy_ecs::entity`: - `Entity::index` and `Entity::generation` are no longer `pub(crate)`, opting to force the rest of bevy_ecs to use the public interface to access these values. - `EntityMeta` is no longer `pub` and also not `pub(crate)` to attempt to cut down on updating `generation` without going through an `Entities` API. It's currently inaccessible except via the `pub(crate)` Vec on `Entities`, there was no way for an outside user to use it. - Added `Entities::set`, an unsafe `pub(crate)` API for setting the location of an Entity (parallel to `Entities::get`) that replaces the internal case where we need to set the location of an entity when it's been spawned, moved, or despawned. - `Entities::alloc_at_without_replacement` is only used in `World::get_or_spawn` within the first party crates, and I cannot find a public use of this API in any ecosystem crate that I've checked (via GitHub search). - Attempted to document the few remaining undocumented public APIs in the module. --- ## Changelog Removed: `Entities`'s `Default` implementation. Removed: `EntityMeta` Removed: `Entities::alloc_at_without_replacement` and `AllocAtWithoutReplacement`. Co-authored-by: james7132 <contact@jamessliu.com> Co-authored-by: James Liu <contact@jamessliu.com>

…ignoring `.DS_Store` files created by macOS Finder (bevyengine#6499) # Objective Finder in macOS creates hidden `.DS_Store` files containing metadata (for icon positioning, view mode, etc) whenever you browse a directory. There's no point in committing these to git, and they're a common git + macOS nuisance. ## Solution - ~~This PR adds `.DS_Store` files to `.gitignore`, improving the developer experience on macOS.~~ - This PR adds a note to the `CONTRIBUTING.md` file teaching how to use global git ignore.

# Objective - run examples is failing with `xvfb-run: error: Xvfb failed to start` ## Solution - rollback ubuntu version for run-examples to 20.04. latest is 22.04 ## Notes - this is just a quick fix and someone should probably get it working on 22.04. I'll make an issue for that if this gets merged.

# Objective - pin nightly to 2022-11-28 to fix miri

…ngine#6658) # Objective The global_vs_local_translation example tries to use transparency to identify static cubes, but the materials of those cubes aren't transparent. ## Solution Change material alpha_mode to `AlphaMode::Blend` for those cubes.

…entId` (bevyengine#6683) # Objective Fixes bevyengine#6682 ## Solution Add `EntityRef::get_change_ticks_by_id` Add `EntityMut::get_change_ticks_by_id` Co-authored-by: Aleksandr Belkin <sQu1rr@users.noreply.github.com>

Co-authored-by: devil-ira <justthecooldude@gmail.com>

…d of passing alpha around)

* Adding a new section concerning the maintainers of the repo # Objective - Adding a few helpful links in the CONTRIBUTING.md files - Fixes bevyengine#6221 ## Solution - Modifying CONTRIBUTING.md - Adding a new section dedicated to maintainers in CONTRIBUTING.md --- Co-authored-by: Ptipiak <Ptipiak.off@gmail.com>

# Objective > Followup to [this](bevyengine#6755 (comment)) comment Rearrange the impls in the `impls/std.rs` file. The issue was that I had accidentally misplaced the impl for `Option<T>` and put it between the `Cow<'static, str>` impls. This is just a slight annoyance and readability issue. ## Solution Move the `Option<T>` and `&'static Path` impls around to be more readable.

# Objective Fixes bevyengine#6827 ## Solution Use the `Color::rgba_linear` function instead of the `Color::rgba` function to correctly interpret colors from glTF files in the linear color space rather than the incorrect sRGB color space

Updates the requirements on [tracing-chrome](https://github.com/thoren-d/tracing-chrome) to permit the latest version. <details> <summary>Release notes</summary> Sourced from <a href="https://github.com/thoren-d/tracing-chrome/releases">tracing-chrome's releases</a>. <blockquote> <h2>Release v0.7.0</h2> <ul> <li>Add <code>start_new</code> to <code>FlushGuard</code>. You can now generate multiple traces in one run!</li> <li>Clean up dependencies</li> <li>Make events thread-scoped</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/8760d81206ba43a16484b1c5f458290a9a6c9a4c"><code>8760d81</code></a> Prepare for 0.7 (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/16">#16</a>)</li> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/a30bfb78d2010c7ef1e9f519e6dc567a731c8021"><code>a30bfb7</code></a> Update documentation (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/15">#15</a>)</li> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/3fe24ff44de9d0d0bf585d5582d6ca9b14800e2d"><code>3fe24ff</code></a> Save thread names for start_new (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/14">#14</a>)</li> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/fa8a0ff8bac7dce14baf1df01092cf3bf883c5cc"><code>fa8a0ff</code></a> Adding "Start New" feature that allows a user to finalize writing to the (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/11">#11</a>)</li> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/d3059d66b356b113246f7dad012509bb9e96c380"><code>d3059d6</code></a> Directly depend on crossbeam_channel (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/12">#12</a>)</li> <li><a href="https://github.com/thoren-d/tracing-chrome/commit/441dba5c212f2ae91d4ffc8ba45ccdfa5f2e9b37"><code>441dba5</code></a> change scope of instant events to thread (<a href="https://github-redirect.dependabot.com/thoren-d/tracing-chrome/issues/13">#13</a>)</li> <li>See full diff in <a href="https://github.com/thoren-d/tracing-chrome/compare/v0.6.0...v0.7.0">compare view</a></li> </ul> </details> 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> 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 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>

# Objective Currently, the `SystemParam` derive forces you to declare the lifetime parameters `<'w, 's>`, even if you don't use them. If you don't follow this structure, the error message is quite nasty. ### Example (before): ```rust #[derive(SystemParam)] pub struct EventWriter<'w, 's, E: Event> { events: ResMut<'w, Events<E>>, // The derive forces us to declare the `'s` lifetime even though we don't use it, // so we have to add this `PhantomData` to please rustc. #[system_param(ignore)] _marker: PhantomData<&'s ()>, } ``` ## Solution * Allow the user to omit either lifetime. * Emit a descriptive error if any lifetimes used are invalid. ### Example (after): ```rust #[derive(SystemParam)] pub struct EventWriter<'w, E: Event> { events: ResMut<'w, Events<E>>, } ``` --- ## Changelog * The `SystemParam` derive is now more flexible, allowing you to omit unused lifetime parameters.

…#6843) # Objective Partially addresses bevyengine#5504. Allow users to get an `Iterator<Item = EntityRef<'a>>` over all entities in the `World`. ## Solution Change `World::iter_entities` to return an iterator of `EntityRef` instead of `Entity`. Not sure how to tackle making an `Iterator<Item = EntityMut<'_>>` without being horribly unsound. Might need to wait for `LendingIterator` to stabilize so we can ensure only one of them is valid at a given time. --- ## Changelog Changed: `World::iter_entities` now returns an iterator of `EntityRef` instead of `Entity`.

# Objective These functions were deprecated in 0.9. They should be removed in 0.10. ## Solution Remove them.

…`bevy_ecs` crate (bevyengine#6816) # Objective - Fixes bevyengine#6812. ## Solution - Replaced `World::read_change_ticks` with `World::change_ticks` within `bevy_ecs` crate in places where `World` references were mutable. ---

…ngine#6823) Co-authored-by: devil-ira <justthecooldude@gmail.com>

The PR fixes the interface of `EventReader::clear`. Currently, the method consumes the reader, which makes it unusable. ## Changelog - `EventReader::clear` now takes a mutable reference instead of consuming the event reader. ## Migration Guide `EventReader::clear` now takes a mutable reference instead of consuming the event reader. This means that `clear` now needs explicit mutable access to the reader variable, which previously could have been omitted in some cases: ```rust // Old (0.9) fn clear_events(reader: EventReader<SomeEvent>) { reader.clear(); } // New (0.10) fn clear_events(mut reader: EventReader<SomeEvent>) { reader.clear(); } ``` Co-authored-by: Carter Anderson <mcanders1@gmail.com>

bevyengine#6765) # Objective The methods `World::change_tick` and `World::read_change_tick` lack documentation and have confusingly similar behavior. ## Solution Add documentation and clarify the distinction between the two functions.

) # Objective Fixes bevyengine#6756 ## Solution Removes the variant wherever it's used Co-authored-by: Jay Pavlina <jay@enjin.io>

… Image (bevyengine#6671) # Objective `prepare_asset` for Image has an alternate path for texture creation that is used when the image is not compressed and does not contain mipmaps. This additional code path is unnecessary as `render_device.create_texture_with_data()` will handle both cases correctly. ## Solution Use `render_device.create_texture_with_data()` in all cases. Tested successfully with the following examples: - load_gltf - render_to_texture - texture - 3d_shapes - sprite - sprite_sheet - array_texture - shader_material_screenspace_texture - skybox (though this already would use the `create_texture_with_data()` branch anyway)

# Objective - Fixes bevyengine#6711 ## Solution - Change the `path` function parameter of `dynamically_load_plugin` and `DynamicPluginExt::load_plugin` to a generic with `AsRef<OsStr>` bound

# Objective - Fixes bevyengine#3004 ## Solution - Replaced all the types with their fully quallified names - Replaced all trait methods and inherent methods on dyn traits with their fully qualified names - Made a new file `fq_std.rs` that contains structs corresponding to commonly used Structs and Traits from `std`. These structs are replaced by their respective fully qualified names when used inside `quote!`

…ine#6800) # Objective `EntityRef::get` and friends all type erase calls to fetch the target components by using passing in the `TypeId` instead of using generics. This is forcing a lookup to `Components` to fetch the storage type. This adds an extra memory lookup and forces a runtime branch instead of allowing the compiler to optimize out the unused branch. ## Solution Leverage `Component::Storage::STORAGE_TYPE` as a constant instead of fetching the metadata from `Components`. ## Performance This has a near 2x speedup for all calls to `World::get`. Microbenchmark results from my local machine. `Query::get_component`, which uses `EntityRef::get` internally also show a slight speed up. This has closed the gap between `World::get` and `Query::get` for the same use case. ``` group entity-ref-generics main ----- ------------------- ---- query_get_component/50000_entities_sparse 1.00 890.6±40.42µs ? ?/sec 1.10 980.6±28.22µs ? ?/sec query_get_component/50000_entities_table 1.00 968.5±73.73µs ? ?/sec 1.08 1048.8±31.76µs ? ?/sec query_get_component_simple/system 1.00 703.2±4.37µs ? ?/sec 1.00 702.1±6.13µs ? ?/sec query_get_component_simple/unchecked 1.02 855.8±8.98µs ? ?/sec 1.00 843.1±8.19µs ? ?/sec world_get/50000_entities_sparse 1.00 202.3±3.15µs ? ?/sec 1.85 374.0±20.96µs ? ?/sec world_get/50000_entities_table 1.00 193.0±1.78µs ? ?/sec 2.02 389.2±26.55µs ? ?/sec world_query_get/50000_entities_sparse 1.01 162.4±2.23µs ? ?/sec 1.00 161.3±0.95µs ? ?/sec world_query_get/50000_entities_table 1.00 199.9±0.63µs ? ?/sec 1.00 200.2±0.74µs ? ?/sec ``` This should also, by proxy, speed up the `ReflectComponent` APIs as most of those use `World::get` variants internally.

# Objective Prevent future unsoundness that was seen in bevyengine#6623. ## Solution Newtype both indexes in `Archetype` and `Table` as `ArchetypeRow` and `TableRow`. This avoids weird numerical manipulation on the indices, and can be stored and treated opaquely. Also enforces the source and destination of where these indices at a type level. --- ## Changelog Changed: `Archetype` indices and `Table` rows have been newtyped as `ArchetypeRow` and `TableRow`.

# Objective Links to `cargo-flamegraph`'s repo point to a [fork](https://github.com/killercup/cargo-flamegraph), not the actual upstream repo. We should point to the source of truth instead of a fork that hasn't been updated since 2019. ## Solution Change links to point to the upstream repo at [flamegraph-rs/flamegraph](https://github.com/flamegraph-rs/flamegraph).

) # Objective Fixes bevyengine#5199. ## Solution Mention how to compare two different saved tracy traces in the profiling section.

# Objective Fixes bevyengine#6866. ## Solution Docs now should describe what the _front_, _first_, _back_, and _last_ elements are for an implementor of the `bevy::reflect::list::List` Trait. Further, the docs should describe how `bevy::reflect::list::List::push` and `bevy::reflect::list::List::pop` should act on these elements. Co-authored-by: Linus Käll <linus.kall.business@gmail.com>

…evyengine#6877) having `doc(hidden)` on the read only version of a generated mutable world query leads to docs on the readonly item having a dead link. It also makes it annoying to have nice docs for libraries attempting to expose derived `WorldQuery` structs as re-exporting the read only item does not cause it to appear in docs even though it would be intended for users to know about the read only world query and use it.

# Objective - Fixes bevyengine#6841 - In some case, the number of maximum storage buffers is `u32::MAX` which doesn't fit in a `i32` ## Solution - Add an option to have a `u32` in a `ShaderDefVal`

…bs (bevyengine#6875) # Objective - The `run-examples-on-wasm` job fails on Ubuntu 22.04, when it was previously working on Ubuntu 20.04. Playwright 1.22.1 (the version currently pinned by us) fails trying to install system dependencies that were renamed between Ubuntu 20.04 and 22.04. - The `run-examples` job previously failed on Ubuntu 22.04 with errors consistent with those listed in [this upstream mesa bug](https://gitlab.freedesktop.org/mesa/mesa/-/issues/7819). - Fixes bevyengine#6832 ## Solution - Upgrade `playwright` to the latest [v1.28.1](https://github.com/microsoft/playwright/releases/tag/v1.28.1) release. Ubuntu 22.04 support was [added](microsoft/playwright#14588) in [v1.23.0](https://github.com/microsoft/playwright/releases/tag/v1.23.0). The [test now passes on 22.04](https://github.com/oliviacrain/bevy/actions/runs/3633583112/jobs/6130757397), and the output screenshots are unchanged from previous job outputs. - Use `ubuntu-latest` for the `run-examples` job. No other modifications necessary. The [PPA we pull mesa from](https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) rebuilt the package for 22.04 with the [upstream fix](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20145/diffs?commit_id=b3d1ae19f2f4d93cf0a5f45a598149ac4e8e05aa).

) # Objective The window event types currently don't support reflection. This PR adds support to them (as requested [here](bevyengine#6223 (comment))). ## Solution Implement `Reflect` + `FromReflect` for window event types. Relevant traits are also being reflected with `#[reflect(...)]` attributes. Additionally, this PR derives `Reflect` + `FromReflect` for `WindowDescriptor` and the types it depends on so that `CreateWindow` events can be fully manipulated through reflection. Finally, this PR adds `FromReflect` for `PathBuf` as a value type, which is needed for `FileDragAndDrop`. This adds the "glam" feature to the `bevy_reflect` dependency for package `bevy_window`. Since `bevy_window` transitively depends on `glam` already, all this brings in are the reflection `impl`s. ## Open questions Should `app.register_type::<PathBuf>();` be moved to `CorePlugin`? I added it to `WindowPlugin` because that's where it's used and `CorePlugin` doesn't seem to register all the missing std types, but it would also make sense in `CorePlugin` I believe since it's a commonly used type. --- ## Changelog Added: - Implemented `Reflect` + `FromReflect` for window events and related types. These types are automatically registered when adding the `WindowPlugin`.

# Objective bevyengine#6547 accidentally broke change detection for SparseSet components by using `Ticks::from_tick_cells` with the wrong argument order. ## Solution Use the right argument order. Add a regression test.

# Objective Resolves bevyengine#4597 (based on the work from bevyengine#6056 and a refresh of bevyengine#4147) When using reflection, we may often end up in a scenario where we have a Dynamic representing a certain type. Unfortunately, we can't just call `MyType::from_reflect` as we do not have knowledge of the concrete type (`MyType`) at runtime. Such scenarios happen when we call `Reflect::clone_value`, use the reflection deserializers, or create the Dynamic type ourselves. ## Solution Add a `ReflectFromReflect` type data struct. This struct allows us to easily convert Dynamic representations of our types into their respective concrete instances. ```rust #[derive(Reflect, FromReflect)] #[reflect(FromReflect)] // <- Register `ReflectFromReflect` struct MyStruct(String); let type_id = TypeId::of::<MyStruct>(); // Register our type let mut registry = TypeRegistry::default(); registry.register::<MyStruct>(); // Create a concrete instance let my_struct = MyStruct("Hello world".to_string()); // `Reflect::clone_value` will generate a `DynamicTupleStruct` for tuple struct types let dynamic_value: Box<dyn Reflect> = my_struct.clone_value(); assert!(!dynamic_value.is::<MyStruct>()); // Get the `ReflectFromReflect` type data from the registry let rfr: &ReflectFromReflect = registry .get_type_data::<ReflectFromReflect>(type_id) .unwrap(); // Call `FromReflect::from_reflect` on our Dynamic value let concrete_value: Box<dyn Reflect> = rfr.from_reflect(&dynamic_value); assert!(concrete_value.is::<MyStruct>()); ``` ### Why this PR? ###### Why now? The three main reasons I closed bevyengine#4147 were that: 1. Registering `ReflectFromReflect` is clunky (deriving `FromReflect` *and* registering `ReflectFromReflect`) 2. The ecosystem and Bevy itself didn't seem to pay much attention to deriving `FromReflect` 3. I didn't see a lot of desire from the community for such a feature However, as time has passed it seems 2 and 3 are not really true anymore. Bevy is internally adding lots more `FromReflect` derives, which should make this feature all the more useful. Additionally, I have seen a growing number of people look for something like `ReflectFromReflect`. I think 1 is still an issue, but not a horrible one. Plus it could be made much, much better using bevyengine#6056. And I think splitting this feature out of bevyengine#6056 could lead to bevyengine#6056 being adopted sooner (or at least make the need more clear to users). ###### Why not just re-open bevyengine#4147? The main reason is so that this PR can garner more attention than simply re-opening the old one. This helps bring fresh eyes to the PR for potentially more perspectives/reviews. --- ## Changelog * Added `ReflectFromReflect` Co-authored-by: Gino Valente <49806985+MrGVSV@users.noreply.github.com>

# Objective - Make `AudioOutput` a `Resource`. ## Solution - Do not store `OutputStream` in the struct. - `mem::forget` `OutputStream`. --- ## Changelog ### Added - `AudioOutput` is now a `Resource`. ## Migration Guide - Use `Res<AudioOutput<Source>>` instead of `NonSend<AudioOutput<Source>>`. Same for `Mut` variants.

# Objective Document `World::clear_trackers()`. ## Solution Document the `World::clear_trackers()` method, and briefly how it's related to change detection and `RemovedComponents`. This is a follow-up from [this discussion](https://discord.com/channels/691052431525675048/749335865876021248/1039628807025479700) on Discord.

…6619) # Objective Fixes bevyengine#6299 ## Solution Change one line of documentation. Co-authored-by: dis-da-moe <84386186+dis-da-moe@users.noreply.github.com>

…gine#6751) # Objective Fixes bevyengine#6224, add ``dbg``, ``info``, ``warn`` and ``error`` system piping adapter variants to expand bevyengine#5776, which call the corresponding re-exported [bevy_log macros](https://docs.rs/bevy/latest/bevy/log/macro.info.html) when the result is an error. ## Solution * Added ``dbg``, ``info``, ``warn`` and ``error`` system piping adapter variants to ``system_piping.rs``. * Modified and added tests for these under examples in ``system_piping.rs``.

@rparrett

# Objective Adds a cylinder shape. Fixes bevyengine#2282. ## Solution - I added a custom cylinder shape, taken from [here](https://github.com/rparrett/typey_birb/blob/main/src/cylinder.rs) with permission from @rparrett. - I also added the cylinder shape to the `3d_shapes` example scene. --- ## Changelog - Added cylinder shape Co-Authored-By: Rob Parrett <robparrett@gmail.com> Co-Authored-By: davidhof <7483215+davidhof@users.noreply.github.com>

# Objective - Get rid of giant match statement to get PixelInfo. - This will allow for supporting any texture that is uncompressed, instead of people needing to PR in any textures that are supported in wgpu, but not bevy. ## Solution - More conservative alternative to bevyengine#6788, where we don't try to make some of the calculations correct for compressed types. - Delete `PixelInfo` and get the pixel_size directly from wgpu. Data from wgpu is here: https://docs.rs/wgpu-types/0.14.0/src/wgpu_types/lib.rs.html#2359 - Panic if the texture is a compressed type. An integer byte size of a pixel is no longer a valid concept when talking about compressed textures. - All internal usages use `pixel_size` and not `pixel_info` and are on uncompressed formats. Most of these usages are on either explicit texture formats or slightly indirectly through `TextureFormat::bevy_default()`. The other uses are in `TextureAtlas` and have other calculations that assumes the texture is uncompressed. ## Changelog - remove `PixelInfo` and get `pixel_size` from wgpu ## Migration Guide `PixelInfo` has been removed. `PixelInfo::components` is equivalent to `texture_format.describe().components`. `PixelInfo::type_size` can be gotten from `texture_format.describe().block_size/ texture_format.describe().components`. But note this can yield incorrect results for some texture types like Rg11b10Float.

# Objective This is an adoption of bevyengine#5792. Fixes bevyengine#5791. ## Solution Implemented all the required reflection traits for `VecDeque`, taking from `Vec`'s impls. --- ## Changelog Added: `std::collections::VecDeque` now implements `Reflect` and all relevant traits. Co-authored-by: james7132 <contact@jamessliu.com>

# Objective Fix bevyengine#5292. ## Solution Avoid derefencing when clearing to ensure that change detection is not triggered when there is nothing to clear.

@mockersf

# Objective - Make running animation fluid skipping 'idle' frame. ## Solution - Loop through the specified indices instead of through the whole sprite sheet. The example is correct, is just the feeling that the animation loop is not seamless. Based on the solution suggested by @mockersf in bevyengine#5429.

# Objective - rust-lang/miri#2713 was merged into miri. See if this fixes miri for bevy.

…ine#6864) # Objective It's not clear to users how to handle `!Sync` types as components and resources in the absence of engine level support for them. ## Solution Added a section to `Component`'s and `Resource`'s type level docs on available options for making a type `Sync` when it holds `!Sync` fields, linking `bevy_utils::synccell::SyncCell` and the currently unstable `std::sync::Exclusive`. Also added a compile_fail doctest that illustrates how to apply `SyncCell`. These will break when/if bevyengine#6572 gets merged, at which point these docs should be updated.

# Objective * Implementing a custom `SystemParam` by hand requires implementing three traits -- four if it is read-only. * The trait `SystemParamFetch<'w, 's>` is a workaround from before we had generic associated types, and is no longer necessary. ## Solution * Combine the trait `SystemParamFetch` with `SystemParamState`. * I decided to remove the `Fetch` name and keep the `State` name, since the former was consistently conflated with the latter. * Replace the trait `ReadOnlySystemParamFetch` with `ReadOnlySystemParam`, which simplifies trait bounds in generic code. --- ## Changelog - Removed the trait `SystemParamFetch`, moving its functionality to `SystemParamState`. - Replaced the trait `ReadOnlySystemParamFetch` with `ReadOnlySystemParam`. ## Migration Guide The trait `SystemParamFetch` has been removed, and its functionality has been transferred to `SystemParamState`. ```rust // Before impl SystemParamState for MyParamState { fn init(world: &mut World, system_meta: &mut SystemMeta) -> Self { ... } } impl<'w, 's> SystemParamFetch<'w, 's> for MyParamState { type Item = MyParam<'w, 's>; fn get_param(...) -> Self::Item; } // After impl SystemParamState for MyParamState { type Item<'w, 's> = MyParam<'w, 's>; // Generic associated types! fn init(world: &mut World, system_meta: &mut SystemMeta) -> Self { ... } fn get_param<'w, 's>(...) -> Self::Item<'w, 's>; } ``` The trait `ReadOnlySystemParamFetch` has been replaced with `ReadOnlySystemParam`. ```rust // Before unsafe impl ReadOnlySystemParamFetch for MyParamState {} // After unsafe impl<'w, 's> ReadOnlySystemParam for MyParam<'w, 's> {} ```

# Objective - Fixes bevyengine#6417 ## Solution - clear_trackers was not being called on the render world. This causes the removed components vecs to continuously grow. This PR adds clear trackers to the end of RenderStage::Cleanup ## Migration Guide The call to `clear_trackers` in `App` has been moved from the schedule to App::update for the main world and calls to `clear_trackers` have been added for sub_apps in the same function. This was due to needing stronger guarantees. If clear_trackers isn't called on a world it can lead to memory leaks in `RemovedComponents`.

# Objective ```rust // makes clippy complain about 'taking a mutable reference to a `const` item' let color = *Color::RED.set_a(0.5); // Now you can do let color = Color::RED.with_a(0.5); ``` ## Changelog Added `with_r`, `with_g`, `with_b`, and `with_a` to `Color`. Co-authored-by: devil-ira <justthecooldude@gmail.com>

# Objective - Fixes bevyengine#6630, fixes bevyengine#6679 - Improve scene viewer in cases where there are more than one scene in a gltf file ## Solution - Can select which scene to display using `#SceneN`, defaults to scene 0 if not present - Display the number of scenes available if there are more than one

# Objective Partially address bevyengine#3492. ## Solution Document the remaining undocumented members of `bevy_utils` and set `warn(missing_docs)` on the crate level. Also enabled `clippy::undocumented_unsafe_blocks` as a warning on the crate to keep it in sync with `bevy_ecs`'s warnings.

# Objective Speed up bundle insertion and spawning from a bundle. ## Solution Use the same technique used in bevyengine#6800 to remove the branch on storage type when writing components from a `Bundle` into storage. - Add a `StorageType` argument to the closure on `Bundle::get_components`. - Pass `C::Storage::STORAGE_TYPE` into that argument. - Match on that argument instead of reading from a `Vec<StorageType>` in `BundleInfo`. - Marked all implementations of `Bundle::get_components` as inline to encourage dead code elimination. The `Vec<StorageType>` in `BundleInfo` was also removed as it's no longer needed. If users were reliant on this, they can either use the compile time constants or fetch the information from `Components`. Should save a rather negligible amount of memory. ## Performance Microbenchmarks show a slight improvement to inserting components into existing entities, as well as spawning from a bundle. Ranging about 8-16% faster depending on the benchmark. ``` group main soft-constant-write-components ----- ---- ------------------------------ add_remove/sparse_set 1.08 1019.0±80.10µs ? ?/sec 1.00 944.6±66.86µs ? ?/sec add_remove/table 1.07 1343.3±20.37µs ? ?/sec 1.00 1257.3±18.13µs ? ?/sec add_remove_big/sparse_set 1.08 1132.4±263.10µs ? ?/sec 1.00 1050.8±240.74µs ? ?/sec add_remove_big/table 1.02 2.6±0.05ms ? ?/sec 1.00 2.5±0.08ms ? ?/sec get_or_spawn/batched 1.15 401.4±17.76µs ? ?/sec 1.00 349.3±11.26µs ? ?/sec get_or_spawn/individual 1.13 732.1±43.35µs ? ?/sec 1.00 645.6±41.44µs ? ?/sec insert_commands/insert 1.12 623.9±37.48µs ? ?/sec 1.00 557.4±34.99µs ? ?/sec insert_commands/insert_batch 1.16 401.4±17.00µs ? ?/sec 1.00 347.4±12.87µs ? ?/sec insert_simple/base 1.08 416.9±5.60µs ? ?/sec 1.00 385.2±4.14µs ? ?/sec insert_simple/unbatched 1.06 934.5±44.58µs ? ?/sec 1.00 881.3±47.86µs ? ?/sec spawn_commands/2000_entities 1.09 190.7±11.41µs ? ?/sec 1.00 174.7±9.15µs ? ?/sec spawn_commands/4000_entities 1.10 386.5±25.33µs ? ?/sec 1.00 352.3±18.81µs ? ?/sec spawn_commands/6000_entities 1.10 586.2±34.42µs ? ?/sec 1.00 535.3±27.25µs ? ?/sec spawn_commands/8000_entities 1.08 778.5±45.15µs ? ?/sec 1.00 718.0±33.66µs ? ?/sec spawn_world/10000_entities 1.04 1026.4±195.46µs ? ?/sec 1.00 985.8±253.37µs ? ?/sec spawn_world/1000_entities 1.06 103.8±20.23µs ? ?/sec 1.00 97.6±18.22µs ? ?/sec spawn_world/100_entities 1.15 11.4±4.25µs ? ?/sec 1.00 9.9±1.87µs ? ?/sec spawn_world/10_entities 1.05 1030.8±229.78ns ? ?/sec 1.00 986.2±231.12ns ? ?/sec spawn_world/1_entities 1.01 105.1±23.33ns ? ?/sec 1.00 104.6±31.84ns ? ?/sec ``` --- ## Changelog Changed: `Bundle::get_components` now takes a `FnMut(StorageType, OwningPtr)`. The provided storage type must be correct for the component being fetched.

# Objective - bevyengine#5364 Added a few features to the AsBindGroup derive, but if you don't know they exist they aren't documented anywhere. ## Solution - Document the new arguments in the doc block for the derive.

# Objective The feature doesn't have any use case in libraries or applications and many users use this feature incorrectly. See the issue for details. Closes bevyengine#5753. ## Solution Remove it. --- ## Changelog ### Removed - `render` feature group. ## Migration Guide Instead of using `render` feature group use dependencies directly. This group consisted of `bevy_core_pipeline`, `bevy_pbr`, `bevy_gltf`, `bevy_render`, `bevy_sprite`, `bevy_text` and `bevy_ui`. You probably want to check if you need all of them.

…ne#6914) # Objective The following code: ```rs use bevy::prelude::Image; use image::{ DynamicImage, GenericImage, Rgba }; fn main() { let mut dynamic_image = DynamicImage::new_rgb32f(1, 1); dynamic_image.put_pixel(0, 0, Rgba([1, 1, 1, 1])); let image = Image::from_dynamic(dynamic_image, false); // Panic! println!("{image:?}"); } ``` Can cause an assertion failed: ``` thread 'main' panicked at 'assertion failed: `(left == right)` left: `16`, right: `14`: Pixel data, size and format have to match', .../bevy_render-0.9.1/src/texture/image.rs:209:9 stack backtrace: ... 4: core::panicking::assert_failed<usize,usize> at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:181 5: bevy_render::texture::image::Image::new at .../bevy_render-0.9.1/src/texture/image.rs:209 6: bevy_render::texture::image::Image::from_dynamic at .../bevy_render-0.9.1/src/texture/image_texture_conversion.rs:159 7: bevy_test::main at ./src/main.rs:8 ... ``` It seems to be cause by a copypasta in `crates/bevy_render/src/texture/image_texture_conversion.rs`. Let's fix it. ## Solution ```diff // DynamicImage::ImageRgb32F(image) => { - let a = u16::max_value(); + let a = 1f32; ``` This will fix the conversion. --- ## Changelog - Fixed the alpha channel of the `image::DynamicImage::ImageRgb32F` to `bevy_render::texture::Image` conversion in `bevy_render::texture::Image::from_dynamic()`.

Add a section about install `vulkan-loader` on Gentoo. # Objective - Clarify the dependency about install on Gentoo with NVIDIA GPU and using a proprietary driver. ## Solution - Emerge `vulkan-loader` to help Bevy to find the correct ICD.

… GPUs (bevyengine#6729) fix note in arch's linux deps.

…e#6853) # Objective Change detection can be spuriously triggered by setting a field to the same value as before. As a result, a common pattern is to write: ```rust if *foo != value { *foo = value; } ``` This is confusing to read, and heavy on boilerplate. Adopted from bevyengine#5373, but untangled and rebased to current `bevy/main`. ## Solution 1. Add a method to the `DetectChanges` trait that implements this boilerplate when the appropriate trait bounds are met. 2. Document this minor footgun, and point users to it. ## Changelog * added the `set_if_neq` method to avoid triggering change detection when the new and previous values are equal. This will work on both components and resources. ## Migration Guide If you are manually checking if a component or resource's value is equal to its new value before setting it to avoid triggering change detection, migrate to the clearer and more convenient `set_if_neq` method. ## Context Related to bevyengine#2363 as it avoids triggering change detection, but not a complete solution (as it still requires triggering it when real changes are made). Co-authored-by: Zoey <Dessix@Dessix.net>

# Objective A separate `tracing` span for running a system's commands is created, even if the system doesn't have commands. This is adding extra measuring overhead (see bevyengine#4892) where it's not needed. ## Solution Move the span into `ParallelCommandState` and `CommandQueue`'s `SystemParamState::apply`. To get the right metadata for the span, a additional `&SystemMeta` parameter was added to `SystemParamState::apply`. --- ## Changelog Added: `SystemMeta::name` Changed: Systems without `Commands` and `ParallelCommands` will no longer show a "system_commands" span when profiling. Changed: `SystemParamState::apply` now takes a `&SystemMeta` parameter in addition to the provided `&mut World`.

Co-authored-by: devil-ira <justthecooldude@gmail.com>

…ndencies (bevyengine#6947) # Objective - Get dependency check to succeed ## Solution - Update the list

# Objective [Rust 1.66](https://blog.rust-lang.org/inside-rust/2022/12/12/1.66.0-prerelease.html) is coming in a few days, and bevy doesn't build with it. Fix that. ## Solution Replace output from a trybuild test, and fix a few new instances of `needless_borrow` and `unnecessary_cast` that are now caught. ## Note Due to the trybuild test, this can't be merged until 1.66 is released.

@cart

# Objective `AsBindGroup` can't be used as a trait object because of the constraint `Sized` and because of the associated function. This is a problem for [`bevy_atmosphere`](https://github.com/JonahPlusPlus/bevy_atmosphere) because it needs to use a trait that depends on `AsBindGroup` as a trait object, for switching out different shaders at runtime. The current solution it employs is reimplementing the trait and derive macro into that trait, instead of constraining to `AsBindGroup`. ## Solution Remove the `Sized` constraint from `AsBindGroup` and add the constraint `where Self: Sized` to the associated function `bind_group_layout`. Also change `PreparedBindGroup<T: AsBindGroup>` to `PreparedBindGroup<T>` and use it as `PreparedBindGroup<Self::Data>` instead of `PreparedBindGroup<Self>`. This weakens the constraints, but increases the flexibility of `AsBindGroup`. I'm not entirely sure why the `Sized` constraint was there, because it worked fine without it (maybe @cart wasn't aware of use cases for `AsBindGroup` as a trait object or this was just leftover from legacy code?). --- ## Changelog - `AsBindGroup` can be used as a trait object.

# Objective Remove a method with an unfortunate name and questionable usefulness. Added in bevyengine#4708 It doesn't make sense to me for us to provide a method to work around a limitation of closures when we can simply, *not* use a closure. The limitation in this case is not being able to initialize a variable from inside a closure: ```rust let child_id; commands.spawn_empty().with_children(|parent| { // Error: passing uninitalized variable to a closure. child_id = parent.spawn_empty().id(); }); // Do something with child_id ``` The docs for `add_children` suggest the following: ```rust let child_id = commands .spawn_empty() .add_children(|parent| parent.spawn_empty().id()); ``` I would instead suggest using the following snippet. ```rust let parent_id = commands.spawn_empty().id(); let child_id = commands.spawn_empty().set_parent(parent_id).id(); // To be fair, at the time of bevyengine#4708 this would have been a bit more cumbersome since `set_parent` did not exist. ``` Using `add_children` gets more unwieldy when you also want the `parent_id`. ```rust let parent_commands = commands.spawn_empty(); let parent_id = parent_commands.id(); let child_id = parent_commands.add_children(|parent| parent.spawn_empty().id()); ``` ### The name I see why `add_children` is named that way, it's the non-builder variant of `with_children` so it kinda makes sense, but now the method name situation for `add_child`, `add_children` and `push_children` is *rather* unfortunate. Removing `add_children` and renaming `push_children` to `add_children` in one go is kinda bleh, but that way we end up with the matching methods `add_child` and `add_children`. Another reason to rename `push_children` is that it's trying to mimick the `Vec` api naming but fails because `push` is for single elements. I guess it should have been `extend_children_from_slice`, but lets not name it that :) ### Questions ~~Should `push_children` be renamed in this PR? This would make the migration guide easier to deal with.~~ Let's do that later. Does anyone know of a way to do a simple text/regex search through all the github repos for usage of `add_children`? That way we can have a better idea of how this will affect users. My guess is that usage of `add_children` is quite rare. ## Migration Guide The method `add_children` on `EntityCommands` was removed. If you were using `add_children` over `with_children` to return data out of the closure you can use `set_parent` or `add_child` to avoid the closure instead. Co-authored-by: devil-ira <justthecooldude@gmail.com>

# Objective Some settings were only applied in windowed mode. Fix the issue in bevyengine#6933 # Solution Always apply the settings. Co-authored-by: devil-ira <justthecooldude@gmail.com>

# Objective There is currently no way to iterate over key/value pairs inside an `EntityMap`, which makes the usage of this struct very awkward. I couldn't think of a good reason why the `iter()` function should not be exposed, considering the interface already exposes `keys()` and `values()`, so I made this PR. ## Solution Implement `iter()` for `EntityMap` in terms of its inner map type.

# Objective This includes one part of bevyengine#4899. The aim is to improve CPU-side rendering performance by reducing the memory footprint and bandwidth required. ## Solution Shrink `DrawFunctionId` to `u32`. Enforce that `u32 as usize` conversions are always safe by forbidding compilation on 16-bit platforms. This shouldn't be a breaking change since bevyengine#4736 disabled compilation of `bevy_ecs` on those platforms. Shrinking `DrawFunctionId` shrinks all of the `PhaseItem` types, which is integral to sort and render phase performance. Testing against `many_cubes`, the sort phase improved by 22% (174.21us -> 141.76us per frame). ![image](https://user-images.githubusercontent.com/3137680/207345422-a512b4cf-1680-46e0-9973-ea72494ebdfe.png) The main opaque pass also imrproved by 9% (5.49ms -> 5.03ms) ![image](https://user-images.githubusercontent.com/3137680/207346436-cbee7209-6450-4964-b566-0b64cfa4b4ea.png) Overall frame time improved by 5% (14.85ms -> 14.09ms) ![image](https://user-images.githubusercontent.com/3137680/207346895-9de8676b-ef37-4cb9-8445-8493f5f90003.png) There will be a followup PR that likewise shrinks `CachedRenderPipelineId` which should yield similar results on top of these improvements.

# Objective This adds a custom profile for testing against stress tests. Bevy seemingly gets notably faster with LTO turned on. To more accurately depict production level performance, LTO and other rustc-level optimizations should be enabled when performance testing on stress tests. Also updated the stress test docs to reflect that users should be using it.

# Objective - Dynamic scene builder can build scenes without components, if they didn't have any matching the type registry - Those entities are not really useful in the final `DynamicScene` ## Solution - Add a method `remove_empty_entities` that will remove empty entities. It's not called by default when calling `build`, I'm not sure if that's a good idea or not.

# Objective Fix bevyengine#1991. Allow users to have a bit more control over the creation and finalization of the threads in `TaskPool`. ## Solution Add new methods to `TaskPoolBuilder` that expose callbacks that are called to initialize and finalize each thread in the `TaskPool`. Unlike the proposed solution in bevyengine#1991, the callback is argument-less. If an an identifier is needed, `std::thread::current` should provide that information easily. Added a unit test to ensure that they're being called correctly.

# Objective Following bevyengine#4402, extract systems run on the render world instead of the main world, and allow retained state operations on it's resources. We're currently extracting to `ExtractedJoints` and then copying it twice during Prepare. Once into `SkinnedMeshJoints` and again into the actual GPU buffer. This makes bevyengine#4902 obsolete. ## Solution Cut out the middle copy and directly extract joints into `SkinnedMeshJoints` and remove `ExtractedJoints` entirely. This also removes the per-frame allocation that is being made to send `ExtractedJoints` into the render world. ## Performance On my local machine, this halves the time for `prepare_skinned _meshes` on `many_foxes` (195.75us -> 93.93us on average). ![image](https://user-images.githubusercontent.com/3137680/205427455-ab91a8a3-a6b0-4f0a-bd48-e54482c563b2.png) --- ## Changelog Added: `BufferVec::truncate` Added: `BufferVec::extend` Changed: `SkinnedMeshJoints::build` now takes a `&mut BufferVec` instead of a `&mut Vec` as a parameter. Removed: `ExtractedJoints`. ## Migration Guide `ExtractedJoints` has been removed. Read the bound bones from `SkinnedMeshJoints` instead.

…6921) A code-quality PR Also cleans up the helper methods by just importing the `Event` type Co-authored-by: devil-ira <justthecooldude@gmail.com>

…ngine#6946) # Objective The `WgpuSettings` resource is only used during plugin build. Move it into the `RenderPlugin` struct. Changing these settings requires re-initializing the render context, which is currently not supported. If it is supported in the future it should probably be more explicit than changing a field on a resource, maybe something similar to the `CreateWindow` event. ## Migration Guide ```rust // Before (0.9) App::new() .insert_resource(WgpuSettings { .. }) .add_plugins(DefaultPlugins) // After (0.10) App::new() .add_plugins(DefaultPlugins.set(RenderPlugin { wgpu_settings: WgpuSettings { .. }, })) ``` Co-authored-by: devil-ira <justthecooldude@gmail.com>

# Objective - Remove a manual impl block for something that can be derived - Correct a misleading doc comment.

## Objective Bevy UI uses a `MeasureFunc` that preserves the aspect ratio of text, not just images. This means that the extent of flex-items containing text may be calculated incorrectly depending on the ratio of the text size compared to the size of its containing node. Fixes bevyengine#6748 Related to bevyengine#6724 with Bevy 0.9: ![Capture_cols_0 9](https://user-images.githubusercontent.com/27962798/205435999-386d3400-fe9b-475a-aab1-18e61c4c074f.PNG) with this PR (accurately matching the behavior of Flexbox): ![Capture_fixed](https://user-images.githubusercontent.com/27962798/205436005-6bafbcc2-cd87-4eb7-b5c6-9dbcb30fc795.PNG) ## Solution Only perform the aspect ratio calculations if the uinode contains an image. ## Changelog * Added a field `preserve_aspect_ratio` to `CalculatedSize` * The `MeasureFunc` only preserves the aspect ratio when `preserve_aspect_ratio` is true. * `update_image_calculated_size_system` sets `preserve_aspect_ratio` to true for nodes with images.

…ne#6980) # Objective - `bevy_ptr::{Ptr, PtrMut, OwnedPtr}` wrap raw pointers and should be printable using pointer formatting. ## Solution - Add a `core::fmt::Pointer` impl for `Ptr`, `PtrMut` and `OwnedPtr` based on the wrapped `NonNull` pointer. --- ## Changelog - Added a `core::fmt::Pointer` impl to `Ptr`, `PtrMut` and `OwnedPtr`. Co-authored-by: MrGunflame <mrgunflame@protonmail.com>

The Camera link in the UiCameraConfig was not rendered properly by the documentation. # Objective - In the UiCameraConfig page (https://docs.rs/bevy/latest/bevy/prelude/struct.UiCameraConfig.html), a link to the Camera page (https://docs.rs/bevy/latest/bevy/render/camera/struct.Camera.html) is broken. ## Solution - It seems that when using URL fragment specifiers, backtick should not be used. It might be an issue of rust itself. Replacing the URL fragment specifier `[`Camera`]: bevy_render::camera::Camera` with `[Camera]: bevy_render::camera::Camera` solves this.

@alice-i-cecile

…vyengine#6955) # Objective Fixes bevyengine#6862 (oh hey good catch @alice-i-cecile) Bevy was failing to print events from `info!()` and friends to the console if the `trace_tracy` feature was enabled. It shouldn't be doing that. ## Solution The problem was this per-layer filter that was added in bevyengine#4320 to suppress a noisy per-frame event (which Tracy requires in order to properly close out a frame): - The problem event's target was `"bevy_render::renderer"`, not `"tracy"`. - So, the filter wasn't specifically targeting the noisy event. - Without a default, `tracing_subscriber::filter::Targets` will remove _everything_ that doesn't match an explicit target rule. - So, the filter _was_ silencing the noisy event, along with everything else. This PR changes that filter to do what was probably intended in bevyengine#4320: suppress ~any events more verbose than `ERROR` from `bevy_render::renderer`~ the one problematically noisy event, but allow anything else that already made it through the top-level filter_layer. Also, adds a comment to clarify the intent of that filter, since it's otherwise a bit opaque and required some research. --- ## Changelog Fixed a bug that hid console log messages when the `trace_tracy` feature was enabled.

# Objective Currently, only named structs can be used with the `SystemParam` derive macro. ## Solution Remove the restriction. Tuple structs and unit structs are now supported. --- ## Changelog + Added support for tuple structs and unit structs to the `SystemParam` derive macro.

# Objective * The `SystemParam` derive internally uses tuples, which means it is constrained by the 16-field limit on `all_tuples`. * The error message if you exceed this limit is abysmal. * Supercedes bevyengine#5965 -- this does the same thing, but is simpler. ## Solution If any tuples have more than 16 fields, they are folded into tuples of tuples until they are under the 16-field limit.

# Objective Upgrade to Taffy 0.2 ## Solution Do it ## Changelog Upgraded to Taffy 0.2, improving UI layout performance significantly and adding the flexbox `gap` property and `AlignContent::SpaceEvenly`. ## Notes `many_buttons` is 8% faster! speed improvements for more highly nested UIs will be much more dramatic. Great work, Team Taffy.

# Objective - Add "how to adopt pull requests" section. - Fixes bevyengine#5539 ## Solution - Add "how to adopt pull requests" section in [Contributing.md](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md). Co-authored-by: Erick <erickmelovidal@gmail.com>

@bjorn3

…bevyengine#4241) # Objective Fixes bevyengine#4231. ## Solution This PR implements the solution suggested by @bjorn3 : Use an internal property within `App` to detect `App::run()` calls from `Plugin::build()`. --- ## Changelog - panic when App::run() is called from Plugin::build()

# Objective Fixes bevyengine#4729. Continuation of bevyengine#4854. ## Solution Add documentation to `ParamSet` and its methods. Includes examples suggested by community members in the original PR. Co-authored-by: Nanox19435 <50684926+Nanox19435@users.noreply.github.com> Co-authored-by: JoJoJet <21144246+JoJoJet@users.noreply.github.com>

# Objective * Currently, the `SystemParam` derive does not support types with const generic parameters. * If you try to use const generics, the error message is cryptic and unhelpful. * Continuation of the work started in bevyengine#6867 and bevyengine#6957. ## Solution Allow const generic parameters to be used with `#[derive(SystemParam)]`.

…yengine#6926) # Objective Align the hierarchy API between `EntityCommands` and `EntityMut`. Added missing methods to `EntityMut`. Replaced the duplicate `Command` implementations with the ones on `EntityMut` (e.g. The `AddChild` command is now just `world.entity_mut(..).add_child(..)`) Fixed `update_old_parents` not sending `ChildAdded` events. This PR does not add `add_children` to `EntityMut` as I would like to remove it from `EntityCommands` instead in bevyengine#6942. ## Changelog * Added `add_child`, `set_parent` and `remove_parent` to `EntityMut` * Fixed missing `ChildAdded` events Co-authored-by: devil-ira <justthecooldude@gmail.com>

…ngine#6936) # Objective This PR reorganizes majority of the scene viewer example into a module of plugins which then allows reuse of functionality among new or existing examples. In addition, this enables the scene viewer to be more succinct and showcase the distinct cases of camera control and scene control. This work is to support future work in organization and future examples. A more complicated 3D scene example has been requested by the community (bevyengine#6551) which requests functionality currently included in scene_viewer, but previously inaccessible. The future example can now just utilize the two plugins created here. The existing example [animated_fox example] can utilize the scene creation and animation control functionality of `SceneViewerPlugin`. ## Solution - Created a `scene_viewer` module inside the `tools` example folder. - Created two plugins: `SceneViewerPlugin` (gltf scene loading, animation control, camera tracking control, light control) and `CameraControllerPlugin` (controllable camera). - Original `scene_viewer.rs` moved to `scene_viewer/main.rs` and now utilizes the two plugins.

# Objective - Describe the objective or issue this PR addresses. SpritePipelineKey could use more constification. ## Solution Constify SpritePipelineKey implementation. ## Changelog Co-authored-by: AxiomaticSemantics <117950168+AxiomaticSemantics@users.noreply.github.com>

# Objective - alternative to bevyengine#2895 - as mentioned in bevyengine#2535 the uuid based ids in the render module should be replaced with atomic-counted ones ## Solution - instead of generating a random UUID for each render resource, this implementation increases an atomic counter - this might be replaced by the ids of wgpu if they expose them directly in the future - I have not benchmarked this solution yet, but this should be slightly faster in theory. - Bevymark does not seem to be affected much by this change, which is to be expected. - Nothing of our API has changed, other than that the IDs have lost their IMO rather insignificant documentation. - Maybe the documentation could be added back into the macro, but this would complicate the code.

…gine#5735) # Objective - Be able to name the type that `ManualEventReader::iter/iter_with_id` returns and `EventReader::iter/iter_with_id` by proxy. Currently for the purpose of bevyengine#5719 ## Solution - Create a custom `Iterator` type.

Consolidation of all the feedback about bevyengine#6271 as well as the addition of an "unconditionally visible" mode. # Objective The current implementation of the `Visibility` struct simply wraps a boolean.. which seems like an odd pattern when rust has such nice enums that allow for more expression using pattern-matching. Additionally as it stands Bevy only has two settings for visibility of an entity: - "unconditionally hidden" `Visibility { is_visible: false }`, - "inherit visibility from parent" `Visibility { is_visible: true }` where a root level entity set to "inherit" is visible. Note that given the behaviour, the current naming of the inner field is a little deceptive or unclear. Using an enum for `Visibility` opens the door for adding an extra behaviour mode. This PR adds a new "unconditionally visible" mode, which causes an entity to be visible even if its Parent entity is hidden. There should not really be any performance cost to the addition of this new mode. -- The recently added `toggle` method is removed in this PR, as its semantics could be confusing with 3 variants. ## Solution Change the Visibility component into ```rust enum Visibility { Hidden, // unconditionally hidden Visible, // unconditionally visible Inherited, // inherit visibility from parent } ``` --- ## Changelog ### Changed `Visibility` is now an enum ## Migration Guide - evaluation of the `visibility.is_visible` field should now check for `visibility == Visibility::Inherited`. - setting the `visibility.is_visible` field should now directly set the value: `*visibility = Visibility::Inherited`. - usage of `Visibility::VISIBLE` or `Visibility::INVISIBLE` should now use `Visibility::Inherited` or `Visibility::Hidden` respectively. - `ComputedVisibility::INVISIBLE` and `SpatialBundle::VISIBLE_IDENTITY` have been renamed to `ComputedVisibility::HIDDEN` and `SpatialBundle::INHERITED_IDENTITY` respectively. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

# Objective The documentation for camera priority is very confusing at the moment, it requires a bit of "double negative" kind of thinking. # Solution Flipping the wording on the documentation to reflect more common usecases like having an overlay camera and also renaming it to "order", since priority implies that it will override the other camera rather than have both run.

# Objective Fix bevyengine#6983. ## Solution Mark the function `propagate_recursive` as unsafe, and specify the safety invariants through doc comments.

# Objective Any closure with the signature `FnOnce(&mut World)` implicitly implements the trait `Command` due to a blanket implementation. However, this implementation unnecessarily has the `Sync` bound, which limits the types that can be used. ## Solution Remove the bound. --- ## Changelog - `Command` closures no longer need to implement the marker trait `std::marker::Sync`.

# Objective Resolve bevyengine#6156. The most common type of command is one that runs for a single entity. Built-in commands like this can be ergonomically added to the command queue using the `EntityCommands` struct. However, adding custom entity commands to the queue is quite cumbersome. You must first spawn an entity, store its ID in a local, then construct a command using that ID and add it to the queue. This prevents method chaining, which is the main benefit of using `EntityCommands`. ### Example (before) ```rust struct MyCustomCommand(Entity); impl Command for MyCustomCommand { ... } let id = commands.spawn((...)).id(); commmands.add(MyCustomCommand(id)); ``` ## Solution Add the `EntityCommand` trait, which allows directly adding per-entity commands to the `EntityCommands` struct. ### Example (after) ```rust struct MyCustomCommand; impl EntityCommand for MyCustomCommand { ... } commands.spawn((...)).add(MyCustomCommand); ``` --- ## Changelog - Added the trait `EntityCommand`. This is a counterpart of `Command` for types that execute code for a single entity. ## Future Work If we feel its necessary, we can simplify built-in commands (such as `Despawn`) to use this trait.

# Objective Fix bevyengine#5653. ## Solution - Add an example of how systems can be ordered from within a stage. - Update some docs from before bevyengine#4224

# Objective Fix bevyengine#5914. `PipeSystem` cannot be constructed in `const` contexts. ## Solution Add a const `PipeSystem::new` function.

# Objective It is often necessary to update an entity's parent while keeping its GlobalTransform static. Currently it is cumbersome and error-prone (two questions in the discord `#help` channel in the past week) - Part 1 of bevyengine#5475 - Part 2: bevyengine#7024. ## Solution - Add a `reparented_to` method to `GlobalTransform` --- ## Changelog - Add a `reparented_to` method to `GlobalTransform`

# Objective [ndk-glue](https://github.com/rust-mobile/ndk-glue) has been split from `android-ndk-rs` into a separate repository.

# Objective - We already log the adapter info on startup when bevy_render is present. It would be nice to have more info about the system to be able to ask users to submit it in bug reports ## Solution - Use the `sysinfo` crate to get all the information - I made sure it _only_ gets the required informations to avoid unnecessary system request - Add a system that logs this on startup - This system is currently in `bevy_diagnostics` because I didn't really know where to put it. Here's an example log from my system: ```log INFO bevy_diagnostic: SystemInformation { os: "Windows 10 Pro", kernel: "19044", cpu: "AMD Ryzen 7 5800X 8-Core Processor", core_count: "8", memory: "34282242 KB" } ``` --- ## Changelog - Added a new default log when starting a bevy app that logs the system information

…ed (bevyengine#7031) # Objective - Loading a gltf files prints many errors ``` ERROR bevy_ecs::world: Unable to send event `bevy_hierarchy::events::HierarchyEvent` Event must be added to the app with `add_event()` https://docs.rs/bevy/*/bevy/app/struct.App.html#method.add_event ``` - Loading a gltf file create a world for a scene where events are not registered. Executing hierarchy commands on that world should not print error ## Solution - Revert part of bevyengine#6921 - don't use `world.send_event` / `world.send_event_batch` from commands

fixes alsalib dependency for NixOS

…on. (bevyengine#7036) # Objective Fixes bevyengine#6598 In addition, macOS can also support GL backends through ANGLE.

# Objective Scene viewer mouse sensitivity/cursor usage isn't the best it could be atm, so just adding some quick, maybe opinionated, tweaks to make it feel more at home in usage. ## Solution - Mouse delta shouldn't be affected by delta time, it should be more expected that if I move my mouse 1 inch to the right that it should move the in game camera/whatever is controlled the same regardless of FPS. - Uses a magic number of 180.0 for a nice default sensitivity, modeled after Valorant's default sensitivity. - Cursor now gets locked/hidden when rotating the camera to give it more of the effect that you are grabbing the camera.

# Objective All `RenderPhases` follow the same render procedure. The same code is duplicated multiple times across the codebase. ## Solution I simply extracted this code into a method on the `RenderPhase`. This avoids code duplication and makes setting up new `RenderPhases` easier. --- ## Changelog ### Changed You can now set up the rendering code of a `RenderPhase` directly using the `RenderPhase::render` method, instead of implementing it manually in your render graph node.

# Objective Bevy uses custom `Ptr` types so the rust borrow checker can help ensure lifetimes are correct, even when types aren't known. However, these types don't benefit from the automatic lifetime coercion regular rust references enjoy ## Solution Add a couple methods to Ptr, PtrMut, and MutUntyped to allow for easy usage of these types in more complex scenarios. ## Changelog - Added `as_mut` and `as_ref` methods to `MutUntyped`. - Added `shrink` and `as_ref` methods to `PtrMut`. ## Migration Guide - `MutUntyped::into_inner` now marks things as changed.

bevyengine#7033) # Objective `TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES` was already included in `adapter.features()` on non-wasm target, and since it is the default value for `WgpuSettings.features`, the subsequent code will also combine into this feature: https://github.com/bevyengine/bevy/blob/b6066c30b6cfa7bffa598d45706dbe6e46ad24fc/crates/bevy_render/src/renderer/mod.rs#L155-L156

# Objective I am new to Bevy. And during my development, I noticed that the `iOS` example doesn't work. Example panics with next message: ```panicked at 'Resource requested by bevy_ui::widget::text::text_system does not exist: bevy_asset::assets::Assets```. I have asked for help in a `discord` iOS chat and there I receive a recommendation that it is possible that some bevy features missing. ## Solution So, I used ```bevy``` with default features.

# Objective - Fixes bevyengine#7047 ## Solution - Pass the correct view entity

# Objective `xlibsWrapper` is being deprecated: NixOS/nixpkgs#194054, this pr removes the deprecated xlibsWrapper and makes a couple more improvements ## Solution - rename NixOS to Nix since this is not specific to NixOS - remove usage of `xlibsWrapper` - add instructions for nix flakes with `nix develop` - add example of a packaged bevy program in nixpkgs - minor cosmetic/grammatical changes

Old comment is Z-up , Fix comment for bevy Y-up # Objective - Update Box vertices comment for bevy Y-up ## Solution - Update comment for Y-up --- ## Changelog None ## Migration Guide None

…e#5911) # Objective Solve bevyengine#5464 ## Solution Adds a `SystemInformationDiagnosticsPlugin` to add diagnostics. Adds `Cargo.toml` flags to fix building on different platforms. --- ## Changelog Adds `sysinfo` crate to `bevy-diagnostics`. Changes in import order are due to clippy. Co-authored-by: l1npengtul <35755164+l1npengtul@users.noreply.github.com> Co-authored-by: IceSentry <c.giguere42@gmail.com>

# Objective There isn't really a way to test that code using bevy_reflect compiles or doesn't compile for certain scenarios. This would be especially useful for macro-centric PRs like bevyengine#6511 and bevyengine#6042. ## Solution Using `bevy_ecs_compile_fail_tests` as reference, added the `bevy_reflect_compile_fail_tests` crate. Currently, this crate contains a very simple test case. This is so that we can get the basic foundation of this crate agreed upon and merged so that more tests can be added by other PRs. ### Open Questions - [x] Should this be added to CI? (Answer: Yes) --- ## Changelog - Added the `bevy_reflect_compile_fail_tests` crate for testing compilation errors

@BoxyUwU

# Objective `Query::get` and other random access methods require looking up `EntityLocation` for every provided entity, then always looking up the `Archetype` to get the table ID and table row. This requires 4 total random fetches from memory: the `Entities` lookup, the `Archetype` lookup, the table row lookup, and the final fetch from table/sparse sets. If `EntityLocation` contains the table ID and table row, only the `Entities` lookup and the final storage fetch are required. ## Solution Add `TableId` and table row to `EntityLocation`. Ensure it's updated whenever entities are moved around. To ensure `EntityMeta` does not grow bigger, both `TableId` and `ArchetypeId` have been shrunk to u32, and the archetype index and table row are stored as u32s instead of as usizes. This should shrink `EntityMeta` by 4 bytes, from 24 to 20 bytes, as there is no padding anymore due to the change in alignment. This idea was partially concocted by @BoxyUwU. ## Performance This should restore the `Query::get` "gains" lost to bevyengine#6625 that were introduced in bevyengine#4800 without being unsound, and also incorporates some of the memory usage reductions seen in bevyengine#3678. This also removes the same lookups during add/remove/spawn commands, so there may be a bit of a speedup in commands and `Entity{Ref,Mut}`. --- ## Changelog Added: `EntityLocation::table_id` Added: `EntityLocation::table_row`. Changed: `World`s can now only hold a maximum of 232- 1 archetypes. Changed: `World`s can now only hold a maximum of 232 - 1 tables. ## Migration Guide A `World` can only hold a maximum of 232 - 1 archetypes and tables now. If your use case requires more than this, please file an issue explaining your use case.

…ine#7043) # Objective - The recently merged PR bevyengine#7013 does not allow multiple `RenderPhase`s to share the same `RenderPass`. - Due to the introduced overhead we want to minimize the number of `RenderPass`es recorded during each frame. ## Solution - Take a constructed `TrackedRenderPass` instead of a `RenderPassDiscriptor` as a parameter to the `RenderPhase::render` method. --- ## Changelog To enable multiple `RenderPhases` to share the same `TrackedRenderPass`, the `RenderPhase::render` signature has changed. ```rust pub fn render<'w>( &self, render_pass: &mut TrackedRenderPass<'w>, world: &'w World, view: Entity) ``` Co-authored-by: Kurt Kühnert <51823519+kurtkuehnert@users.noreply.github.com>

…ngine#7069) # Objective - The bevyengine#7064 PR had poor performance on an M1 Max in MacOS due to significant overuse of registers resulting in 'register spilling' where data that would normally be stored in registers on the GPU is instead stored in VRAM. The latency to read from/write to VRAM instead of registers incurs a significant performance penalty. - Use of registers is a limiting factor in shader performance. Assignment of a struct from memory to a local variable can incur copies. Passing a variable that has struct type as an argument to a function can also incur copies. As such, these two cases can incur increased register usage and decreased performance. ## Solution - Remove/avoid a number of assignments of light struct type data to local variables. - Remove/avoid a number of passing light struct type variables/data as value arguments to shader functions.

…ix and undo fix from bevyengine#6802

Commits on Nov 29, 2022

Fix unnecessary conversions

StarLederer committed Nov 29, 2022

Configuration menu

View commit details

Copy full SHA for aea919a

Browse repository at this point

Copy the full SHA

aea919a View commit details

Browse the repository at this point in the history

Further bloom improvements #4

Further bloom improvements #4

Commits on Nov 15, 2022

Commits on Nov 16, 2022

Commits on Nov 18, 2022

Commits on Nov 21, 2022

Commits on Nov 22, 2022

Commits on Nov 23, 2022

Commits on Nov 25, 2022

Commits on Nov 26, 2022

Commits on Nov 27, 2022

Commits on Nov 28, 2022

Commits on Nov 29, 2022

Commits on Nov 30, 2022

Commits on Dec 1, 2022

Commits on Dec 2, 2022

Commits on Dec 3, 2022

Commits on Dec 4, 2022

Commits on Dec 5, 2022

Commits on Dec 6, 2022

Commits on Dec 7, 2022

Commits on Dec 8, 2022

Commits on Dec 9, 2022

Commits on Dec 10, 2022

Commits on Dec 11, 2022

Commits on Dec 13, 2022

Commits on Dec 14, 2022

Commits on Dec 15, 2022

Commits on Dec 16, 2022

Commits on Dec 20, 2022

Commits on Dec 21, 2022

Commits on Dec 22, 2022

Commits on Dec 24, 2022

Commits on Dec 25, 2022

Commits on Dec 26, 2022

Commits on Dec 27, 2022

Commits on Dec 28, 2022

Commits on Dec 29, 2022

Commits on Jan 2, 2023

Commits on Jan 3, 2023