Some clipboard tweaks #9

andrewzhurov · 2025-07-09T16:47:35Z

Hola!
So, tried that async-first approach, so all clipboard-related stuff happens in async Task, on IoTaskPool,
and simple&easy sync api just block_on(<that_task>). 🎉

(if user uses async API to fetch some text, I guess it's up to him to store that Task somewhere and poll when it's finished, but hey, if they invisigate "blocking may be harfmul for us" - they're likely capable of doing so! 😄)
(would be nicer if we'd have some task.add_observer(handle_pasted_text) API tho)

& some other misc.

# Objective - bevy_asset has a clippy warning in wasm: [`clippy::io_other_error`](https://rust-lang.github.io/rust-clippy/master/index.html#io_other_error) ``` error: this can be `std::io::Error::other(_)` --> crates/bevy_asset/src/io/wasm.rs:50:9 | 50 | std::io::Error::new(std::io::ErrorKind::Other, message) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#io_other_error = note: `-D clippy::io-other-error` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::io_other_error)]` help: use `std::io::Error::other` | 50 - std::io::Error::new(std::io::ErrorKind::Other, message) 50 + std::io::Error::other(message) ``` ## Solution - Fix it ## Testing `cargo clippy --target wasm32-unknown-unknown -p bevy_asset --no-deps -- -D warnings`

# Objective - bevy_winit has a warning when compiling without default feature on linux - bevy_winit has a clippy warning when compiling in wasm ## Solution - Fix them ## Testing ``` cargo build -p bevy_winit --no-default-features --features winit/x11 cargo clippy --target wasm32-unknown-unknown -p bevy_winit --no-deps -- -D warnings ```

# Objective - avoid several internal vec copies while collecting all the level data in ktx2 load - merge another little piece of bevyengine#18411 (benchmarks there found this to be a significant win) ## Solution - reserve and extend ## Testing - ran a few examples that load ktx2 images, like ssr. looks fine ## Future work - fast path logic to skip the reading into different vecs and just read it all in one go into the final buffer instead - as above, but directly into gpu staging buffer perhaps

# Objective - bevy_render has unfulfilled expected clippy lints in wasm ## Solution - Don't expect them in wasm ## Testing `cargo clippy --target wasm32-unknown-unknown -p bevy_render --no-deps -- -D warnings`

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

# Objective - Fixes bevyengine#19670 ## Solution - Updated breaking code to be able to upgrade `ui_test` to the latest version. ## Testing - CI checks. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

# Objective - bevy_window fails to compile without default features ``` error: cannot find derive macro `Reflect` in this scope --> crates/bevy_window/src/window.rs:1474:60 | 1474 | #[derive(Default, Debug, Clone, Copy, PartialEq, Eq, Hash, Reflect)] | ^^^^^^^ warning: unused import: `format` --> crates/bevy_window/src/window.rs:1:30 | 1 | use alloc::{borrow::ToOwned, format, string::String}; | ^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: `bevy_window` (lib) generated 1 warning error: could not compile `bevy_window` (lib) due to 1 previous error; 1 warning emitted ``` ## Solution - Fix them ## Testing `cargo build -p bevy_window --no-default-features --features bevy_math/libm`

# Objective add support for light textures (also known as light cookies, light functions, and light projectors) ![image](https://github.com/user-attachments/assets/afdb23e2-b35f-4bf0-bf92-f883cd7db771) ## Solution - add components: ```rs /// Add to a [`PointLight`] to add a light texture effect. /// A texture mask is applied to the light source to modulate its intensity, /// simulating patterns like window shadows, gobo/cookie effects, or soft falloffs. pub struct PointLightTexture { /// The texture image. Only the R channel is read. pub image: Handle<Image>, /// The cubemap layout. The image should be a packed cubemap in one of the formats described by the [`CubemapLayout`] enum. pub cubemap_layout: CubemapLayout, } /// Add to a [`SpotLight`] to add a light texture effect. /// A texture mask is applied to the light source to modulate its intensity, /// simulating patterns like window shadows, gobo/cookie effects, or soft falloffs. pub struct SpotLightTexture { /// The texture image. Only the R channel is read. /// Note the border of the image should be entirely black to avoid leaking light. pub image: Handle<Image>, } /// Add to a [`DirectionalLight`] to add a light texture effect. /// A texture mask is applied to the light source to modulate its intensity, /// simulating patterns like window shadows, gobo/cookie effects, or soft falloffs. pub struct DirectionalLightTexture { /// The texture image. Only the R channel is read. pub image: Handle<Image>, /// Whether to tile the image infinitely, or use only a single tile centered at the light's translation pub tiled: bool, } ``` - store images to the `RenderClusteredDecals` buffer - read the image and modulate the lights - add `light_textures` example to showcase the new features ## Testing see light_textures example

# Objective Fixes bevyengine#19356 Issue: Spawning a batch of entities in relationship with the same target adds the relationship between the target and only the last entity of the batch. `spawn_batch` flushes only after having spawned all entities. This means each spawned entity will have run the `on_insert` hook of its `Relationship` component. Here is the relevant part of that hook: ```Rust if let Some(mut relationship_target) = target_entity_mut.get_mut::<Self::RelationshipTarget>() { relationship_target.collection_mut_risky().add(entity); } else { let mut target = <Self::RelationshipTarget as RelationshipTarget>::with_capacity(1); target.collection_mut_risky().add(entity); world.commands().entity(target_entity).insert(target); } ``` Given the above snippet and since there's no flush between spawns, each entity finds the target without a `RelationshipTarget` component and defers the insertion of that component with the entity's id as the sole member of its collection. When the commands are finally flushed, each insertion after the first replaces the one before and in the process triggers the `on_replace` hook of `RelationshipTarget` which removes the `Relationship` component from the corresponding entity. That's how we end up in the invalid state. ## Solution I see two possible solutions 1. Flush after every spawn 2. Defer the whole code snippet above I don't know enough about bevy as a whole but 2. seems much more efficient to me. This is what I'm proposing here. I have a doubt though because I've started to look at bevyengine#19348 that 1. would fix as well. ## Testing I added a test for the issue. I've put it in `relationship/mod.rs` but I could see it in `world/spawn_batch.rs` or `lib.rs` because the test is as much about `spawn_batch` as it is about relationships.

# Objective - A step towards bevyengine#19024. - `AnimationGraph` can serialize raw `AssetId`s. However for normal handles, this is a runtime ID. This means it is unlikely that the `AssetId` will correspond to the same asset after deserializing - effectively breaking the graph. ## Solution - Stop allowing `AssetId` to be serialized by `AnimationGraph`. Serializing a handle with no path is now an error. - Add `MigrationSerializedAnimationClip`. This is an untagged enum for serde, meaning that it will take the first variant that deserializes. So it will first try the "modern" version, then it will fallback to the legacy version. - Add some logging/error messages to explain what users should do. Note: one limitation here is that this removes the ability to serialize and deserialize UUIDs. In theory, someone could be using this to have a "default" animation. If someone inserts an empty `AnimationClip` into the `Handle::default()`, this **might** produce a T-pose. It might also do nothing though. Unclear! I think this is worth the risk for simplicity as it seems unlikely that people are sticking UUIDs in here (or that you want a default animation in **any** AnimationGraph). ## Testing - Ran `cargo r --example animation_graph -- --save` on main, then ran `cargo r --example animation_graph` on this PR. The PR was able to load the old data (after bevyengine#19631).

…weak handles. (bevyengine#19634) # Objective - A step towards bevyengine#19024. - The logic here was kinda complex before. ## Solution - I've restructured the logic here while preserving the behavior (as far as I can tell). - We no longer return the handle if it was passed in. The caller should already have access to it, and the returned handle will be a weak handle, not a strong handle (which can cause issues). This prevents us from needing weak handles at all here. - I verified the callers do not need the return value. The only callsite that needs the returned handle does not pass in the input_handle argument. ## Testing - CI

# Objective Fixes sprite picking when using a viewport. Related to bevyengine#19744. ## Solution - Do not substract `viewport.min` as `Camera::viewport_to_world` already does that. - Skip pointers outside the viewport. ## Testing Tested with the following example: <details> <summary>Click to expand code</summary> ```rust use bevy::{ prelude::*, render::camera::Viewport, window::SystemCursorIcon, winit::cursor::CursorIcon, }; fn main() -> AppExit { App::new() .add_plugins(DefaultPlugins) .add_systems(Startup, setup) .insert_resource(ClearColor(Color::BLACK)) .run() } fn setup(mut commands: Commands, window: Single<&Window>) { commands.spawn(( Camera2d, Camera { clear_color: ClearColorConfig::Custom(Color::WHITE), viewport: Some(Viewport { physical_position: UVec2::new( window.physical_width() / 4, window.physical_height() / 4, ), physical_size: UVec2::new( window.physical_width() / 2, window.physical_height() / 2, ), ..default() }), ..default() }, )); commands .spawn(( Transform::from_xyz(100.0, 100.0, 0.0), Sprite::from_color(Color::srgb(0.0, 1.0, 0.0), Vec2::new(200.0, 200.0)), Pickable::default(), )) .observe( |trigger: On<Pointer<Drag>>, mut transform: Query<&mut Transform>| { let mut transform = transform.get_mut(trigger.target()).unwrap(); transform.translation.x += trigger.delta.x; transform.translation.y -= trigger.delta.y; }, ) .observe( |_: On<Pointer<DragStart>>, window: Single<Entity, With<Window>>, mut commands: Commands| { commands .entity(*window) .insert(CursorIcon::from(SystemCursorIcon::Grabbing)); }, ) .observe( |_: On<Pointer<DragEnd>>, window: Single<Entity, With<Window>>, mut commands: Commands| { commands.entity(*window).remove::<CursorIcon>(); }, ); } ``` </details>

# Objective Fixes bevyengine#19692 ## Solution - Skip pointers outside the viewport. ## Testing Tested with the following example: <details> <summary>Click to expand code</summary> ```rust use bevy::{ prelude::*, render::camera::Viewport, window::SystemCursorIcon, winit::cursor::CursorIcon, }; fn main() -> AppExit { App::new() .add_plugins(DefaultPlugins) .add_systems(Startup, setup) .insert_resource(ClearColor(Color::BLACK)) .run() } fn setup(mut commands: Commands, window: Single<&Window>) { // commands.spawn(( Camera2d, Camera { clear_color: ClearColorConfig::Custom(Color::WHITE), viewport: Some(Viewport { physical_position: UVec2::new( window.physical_width() / 4, window.physical_height() / 4, ), physical_size: UVec2::new( window.physical_width() / 2, window.physical_height() / 2, ), ..default() }), ..default() }, )); commands .spawn(( Node { top: Val::Px(100.0), left: Val::Px(100.0), width: Val::Px(200.0), height: Val::Px(200.0), ..default() }, BackgroundColor(Color::srgb(1.0, 0.0, 0.0)), )) .observe(|trigger: On<Pointer<Drag>>, mut node: Query<&mut Node>| { let mut node = node.get_mut(trigger.target()).unwrap(); node.left = Val::Px(px(node.left) + trigger.delta.x); node.top = Val::Px(px(node.top) + trigger.delta.y); }) .observe( |_: On<Pointer<DragStart>>, window: Single<Entity, With<Window>>, mut commands: Commands| { commands .entity(*window) .insert(CursorIcon::from(SystemCursorIcon::Grabbing)); }, ) .observe( |_: On<Pointer<DragEnd>>, window: Single<Entity, With<Window>>, mut commands: Commands| { commands.entity(*window).remove::<CursorIcon>(); }, ); } fn px(val: Val) -> f32 { match val { Val::Px(px) => px, _ => 0.0, } } ``` </details> ## Additional information This is at least also broken on the sprite picking backend. I guess the fix for other backends are also trivial if this is correct. (Sprite picking: bevyengine#19747)

# Objective - Splitted off from bevyengine#19491 - Add some benchmarks for spawning and inserting components. Right now these are pretty short, but it's expected that they will be extended when different kinds of dynamic bundles will be implemented.

# Objective Contributes to bevyengine#18238 Updates the `log_layers_ecs`, example to use the `children!` macro. Note that I did not use a macro, nor `Children::spawn` for the outer layer. Since the `EventReader` is borrowed mutably, any `.map` I did on `events.read()` was going to have the reference outlive the function body. I believe this scope of change is correct for the PR. ## Solution Updates examples to use the Improved Spawning API merged in bevyengine#17521 ## Testing - Did you test these changes? If so, how? - Opened the examples before and after and verified the same behavior was observed. I did this on Ubuntu 24.04.2 LTS using `--features wayland`. - Are there any parts that need more testing? - Other OS's and features can't hurt, but this is such a small change it shouldn't be a problem. - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run the examples yourself with and without these changes. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - see above --- ## Showcase n/a ## Migration Guide n/a Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

# Objective Part of bevyengine#19236 ## Demo ![image](https://github.com/user-attachments/assets/8607f672-de8f-4339-bdfc-817b39f32e3e) https://discord.com/channels/691052431525675048/743663673393938453/1387110701386039317 --------- Co-authored-by: ickshonpe <david.curthoys@googlemail.com>

# Objective - That node has a bunch of query items that are mostly ignored in a few places - Previously this lead to having a long chain of ignored params that was replaced with `..,`. This works, but this seems a bit more likely to break in a subtle way if new parameters are added ## Solution - Split the query in a few groups based on how it was already structured (Mandatory, Optional, Has<T>) ## Testing - None, it's just code style changes

# Objective I was lurking and noticed that some links to the Bevy website were not updated in newer code (`bevyengine.org` -> `bevy.org`). ## Solution - Look for `bevyengine.org` occurrences in the current code, replace them with `bevy.org`. ## Testing - Did you test these changes? If so, how? I visited the Bevy website! - Are there any parts that need more testing? - How can other people (reviewers) test your changes? Is there anything specific they need to know? - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? ## Longer term - Maybe add a lint to flag references to the old website but I don't know how to do that. But not sure it's needed as the more time will pass the less it will be relevant.

…vyengine#19875) # Objective `#[derive(Reflect)]` derives `Typed` impls whose `type_info` methods contain useless calls to `with_custom_attributes` and `with_docs`, e.g.: ``` ::bevy::reflect::NamedField::new::<f32>("x") .with_custom_attributes( ::bevy::reflect::attributes::CustomAttributes::default() ) .with_docs(::core::option::Option::None), ``` This hurts compile times and makes the `cargo expand` output harder to read. It might also hurt runtime speed, depending on whether the compiler can optimize away the no-op methods. Avoiding this will help with bevyengine#19873. ## Solution Check if the attributes/docs are empty before appending the method calls. ## Testing I used `cargo expand` to confirm the useless calls are no longer produced. `-Zmacro-stats` outputs tells me this reduces the size of the `Reflect` impls produced for `bevy_ui` from 1_544_696 bytes to 1_511_214 bytes, a 2.2% drop. Only a small improvement, but it's a start.

…ine#19876) # Objective Most of the impls derived for `#[derive(Reflect)]` have one set of type bounds per field, like so: ``` f32: ::bevy::reflect::FromReflect + ::bevy::reflect::TypePath + ::bevy::reflect::MaybeTyped + ::bevy::reflect::__macro_exports::RegisterForReflection, ``` If multiple fields have the same type, the bounds are repeated uselessly. This can only hurt compile time and clogs up the `cargo expand` output. Avoiding this will help with bevyengine#19873. ## Solution Use a hashset when collecting the bounds to eliminate duplicates. ## Testing I used cargo expand to confirm the duplicate bounds are no longer produced. `-Zmacro-stats` outputs tells me this reduces the size of the `Reflect` code produced for `bevy_ui` from 1_544_696 bytes to 1_467_967 bytes, a 5% drop.

Bumps [cargo-bins/cargo-binstall](https://github.com/cargo-bins/cargo-binstall) from 1.12.5 to 1.14.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/cargo-bins/cargo-binstall/releases">cargo-bins/cargo-binstall's releases</a>.</em></p> <blockquote> <h2>v1.14.1</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Upgrade dependencies</li> </ul> <h2>v1.14.0</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Fix glibc detection on arm Fedora (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2205">#2205</a>)</li> <li>Add support for repository host Codeberg (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2202">#2202</a>)</li> <li>Fix error for missing binaries when <code>--bin</code> does not include any of these missing bins (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/1888">#1888</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2199">#2199</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Rm uninstalled crates from <code>$CARGO_HOME/binstall/crates-v1.json</code> (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2197">#2197</a>)</li> <li>Upgrade dependencies</li> </ul> <h2>v1.13.0</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Add a <code>--bin</code> argument to mirror cargo install <code>--bin</code> (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/1961">#1961</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2189">#2189</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Upgrade dependencies</li> </ul> <h2>v1.12.7</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Fix updating installed crates manifest for custom registry (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2175">#2175</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2178">#2178</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Upgrade transitive dependencies</li> <li>Ensure build script always waits for threads created (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2185">#2185</a>)</li> <li>optimization</li> </ul> <h2>v1.12.6</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4>  </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/8aac5aa2bf0dfaa2863eccad9f43c68fe40e5ec8"><code>8aac5aa</code></a> release: cargo-binstall v1.14.1 (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2211">#2211</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/e5b77406bb70971183d2bc62dd243348b7b82e37"><code>e5b7740</code></a> chore: release (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2210">#2210</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/fe1c5ab94f6fa5abca7bb24639fa392523efb52b"><code>fe1c5ab</code></a> dep: Upgrade transitive dependencies (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2209">#2209</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/151e1ec8c4e4c99f72e3f1be7ad0c7fcda0f5d62"><code>151e1ec</code></a> ci: enable cache-workspace-crates (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2208">#2208</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/abb695a27627ea9a75c0ef93a132551f16685853"><code>abb695a</code></a> build(deps): bump tj-actions/changed-files from 4140eb99d2cced9bfd78375c20883...</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/a1ca1a46abf7b8edeca998dc0d610449d4515709"><code>a1ca1a4</code></a> dep: Replace vergen with vergen-gitcl (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2207">#2207</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/f317ddf23aec11babe1465e20d02f42c39ae7753"><code>f317ddf</code></a> release: cargo-binstall v1.14.0 (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2206">#2206</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/d47e67b0107309bc0038bd50c184448faa0d5f49"><code>d47e67b</code></a> chore: release (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2195">#2195</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/bb9211b72ceec23a8a17d53fad34bcc36a3d2d1d"><code>bb9211b</code></a> Fix glibc detection on Fedora (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2205">#2205</a>)</li> <li><a href="https://github.com/cargo-bins/cargo-binstall/commit/a90dd4569f858e438f8234fd24289093943dbd5a"><code>a90dd45</code></a> feat: Add repository host Codeberg (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2202">#2202</a>)</li> <li>Additional commits viewable in <a href="https://github.com/cargo-bins/cargo-binstall/compare/v1.12.5...v1.14.1">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=cargo-bins/cargo-binstall&package-manager=github_actions&previous-version=1.12.5&new-version=1.14.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com>

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

# Objective - This example uses a FromWorld impl to initialize a resource on startup - bevyengine#19887 ## Solution - Use RenderStartup instead ## Testing - The example still works as expected

# Objective - The MaterialPlugin has some ugly code to initialize some data in the render world - bevyengine#19887 ## Solution - Use the new RenderStartup schedule to use a system instead of using the plugin `finish()` ## Testing - Tested that the 3d_scene and shader_material example still work as expected

Currently, our specialization API works through a series of wrapper structs and traits, which make things confusing to follow and difficult to generalize. This pr takes a different approach, where "specializers" (types that implement `Specialize`) are composable, but "flat" rather than composed of a series of wrappers. The key is that specializers don't *produce* pipeline descriptors, but instead *modify* existing ones: ```rs pub trait Specialize<T: Specializable> { type Key: SpecializeKey; fn specialize( &self, key: Self::Key, descriptor: &mut T::Descriptor ) -> Result<Canonical<Self::Key>, BevyError>; } ``` This lets us use some derive magic to stick multiple specializers together: ```rs pub struct A; pub struct B; impl Specialize<RenderPipeline> for A { ... } impl Specialize<RenderPipeline> for A { ... } #[derive(Specialize)] #[specialize(RenderPipeline)] struct C { // specialization is applied in struct field order applied_first: A, applied_second: B, } type C::Key = (A::Key, B::Key); ``` This approach is much easier to understand, IMO, and also lets us separate concerns better. Specializers can be placed in fully separate crates/modules, and key computation can be shared as well. The only real breaking change here is that since specializers only modify descriptors, we need a "base" descriptor to work off of. This can either be manually supplied when constructing a `Specializer` (the new collection replacing `Specialized[Render/Compute]Pipelines`), or supplied by implementing `HasBaseDescriptor` on a specializer. See `examples/shader/custom_phase_item.rs` for an example implementation. ## Testing - Did some simple manual testing of the derive macro, it seems robust. --- ## Showcase ```rs #[derive(Specialize, HasBaseDescriptor)] #[specialize(RenderPipeline)] pub struct SpecializeMeshMaterial<M: Material> { // set mesh bind group layout and shader defs mesh: SpecializeMesh, // set view bind group layout and shader defs view: SpecializeView, // since type SpecializeMaterial::Key = (), // we can hide it from the wrapper's external API #[key(default)] // defer to the GetBaseDescriptor impl of SpecializeMaterial, // since it carries the vertex and fragment handles #[base_descriptor] // set material bind group layout, etc material: SpecializeMaterial<M>, } // implementation generated by the derive macro impl <M: Material> Specialize<RenderPipeline> for SpecializeMeshMaterial<M> { type Key = (MeshKey, ViewKey); fn specialize( &self, key: Self::Key, descriptor: &mut RenderPipelineDescriptor ) -> Result<Canonical<Self::Key>, BevyError> { let mesh_key = self.mesh.specialize(key.0, descriptor)?; let view_key = self.view.specialize(key.1, descriptor)?; let _ = self.material.specialize((), descriptor)?; Ok((mesh_key, view_key)); } } impl <M: Material> HasBaseDescriptor<RenderPipeline> for SpecializeMeshMaterial<M> { fn base_descriptor(&self) -> RenderPipelineDescriptor { self.material.base_descriptor() } } ``` --------- Co-authored-by: Tim Overbeek <158390905+Bleachfuel@users.noreply.github.com>

# Objective The `EntityEvent` derive macro only parsed the first `entity_event` attr, resulting in the following event having auto propagation silently turned off: ```rust #[derive(Event, EntityEvent)] #[entity_event(traversal = &'static ChildOf)] #[entity_event(auto_propagate)] struct MyEvent; ``` This should either fail to compile or be parsed correctly. ## Solution Parse all `entity_event`. ## Testing Cargo expand the snippet above. I haven't added an extra test for this.

@alice-i-cecile

…e#19855) # Objective Because we want to be able to support more notification options in the future (in addition to just using registered one-shot systems), the `Option<SystemId>` notifications have been changed to a new enum, `Callback`. @alice-i-cecile

…gine#19867) # Objective - This plugin currently does nothing. That's because we add the plugin to the `RenderApp`. Inside the plugin it then looks for the `RenderApp` itself, but since it was added **to** the `RenderApp`, it will never find the `RenderApp`. ## Solution - Move the plugin into build, and more importantly, add it to the app not the render_app.

bevyengine#19890) Previously, the specialize/queue systems were added per-material and the plugin prepass/shadow enable flags controlled whether we added those systems. Now, we make this a property of the material instance and check for it when specializing. Fixes bevyengine#19850.

# Objective - Fixes bevyengine#14698 ## Solution - Refactor all the `SceneSpawner` functions to include a `_dynamic` suffix where appropriate. - Add non-DynamicScene versions of functions on `SceneSpawner`. - Listen for `Scene` `AssetEvent`s and update the corresponding spawned scenes. - Despawn scenes before respawning them. - Store the parent of a scene in its `InstanceInfo`, so that we know where to parent the new entities from a hot-reloaded scene. - Make `InstanceInfo` private (none of our APIs returned it anyway). ## Testing - Ran the `hot_asset_reloading` example and mutated the GLTF to see it be updated. It works! Moving around meshes works in Blender works, deleting meshes also seems to work. - Wrote a test for scene and dynamic scene to ensure they continue to hot-reload. --- ## Migration Guide - Some of the methods on `SceneSpawner` have been renamed: - `despawn` -> `despawn_dynamic` - `despawn_sync` -> `despawn_dynamic_sync` - `update_spawned_scenes` -> `update_spawned_dynamic_scenes` - In their place, we've also added `despawn`, `despawn_sync`, and `update_spawned_scenes` which all act on `Scene`s (as opposed to `DynamicScene`s).

# Objective * The `get_ui_graph` function in bevy_ui's render module is misnamed. It doesn't get the graph, it creates a new one. * `get_ui_graph` shouldn't be called until after we've retrieved each subgraph, otherwise the new UI graph is created for nothing. ## Solution * Rename `get_ui_graph` to `new_ui_graph` * Call `new_ui_graph` only after each subgraph is successful retrieved from the render graph.

…(remade) (bevyengine#19046) # Objective Reopens bevyengine#18961 ## Solution Copy the code ## Testing It worked in the previous pull request ## Showcase See bevyengine#18961 --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

…ine#17209) # Objective Fixes bevyengine#7358 Redo of bevyengine#7360 Ergonomics. There's a bunch of enigmatic boilerplate for constructing a texture for rendering to, which could be greatly simplified for the external user-facing API. ## Solution - Take part of the render_to_target example and turn it into a new constructor for `Image`, with minimal changes beyond the `Default` implementation. - Update the render_to_target example to use the new API. Strictly speaking, there are two small differences between the constructor and the example: ~~1. The example sets the `size` when initially constructing the `Image`, then `resize`s, but `resize` sets the `size` anyway so we don't need to do this extra step.~~ ~~2. The example sets `Image.texture_descriptor.format` to `TextureFormat::Bgra8UnormSrgb`, but the default impl sets this to `TextureFormat::Rgba8UnormSrgb` via `wgpu::TextureFormat::bevy_default()`. I don't know what sort of impact this has, but it works on my machine.~~ I've deliberately chosen to only include `width` and `height` as parameters, but maybe it makes sense for some of the other properties to be exposed as parameters. --- ## Changelog ### Added Added `Image::new_target_texture` constructor for simpler creation of render target textures. --- Notes: - This is a re-do of bevyengine#7360 - there's some relevant discussion on code style there. - The docs for the method want to refer to `bevy_render::camera::Camera` and `bevy_render::camera::RenderTarget::Image`. `bevy_image` used to be part of `bevy_render` and was split out in the past, and `bevy_image` doesn't depend on `bevy_render`. What's the recommendation here? --------- Co-authored-by: Antony <antony.m.3012@gmail.com>

# Objective - Title. ## Solution - Add an explanation of the various traits and structs. - Make VertexLayoutCache private - this type is not used anywhere, and it's just a type alias for a HashMap with no other utility functions. - Rename `specialize_pipeline` argument to `pipeline_specializer` to clarify this is more like a factory than a render pipeline. Technically making `VertexLayoutCache` private is a breaking change, but it seems highly unlikely that anyone is using this (since it's just a hashmap alias. I don't think this needs a migration guide.

…un conditions. (bevyengine#20061) # Objective The `ErrorContext::RunCondition` variant is never used. When reporting errors from a run condition, `ErrorContext::System` is currently used instead. ## Solution Use `ErrorContext::RunCondition` variant when reporting errors from run conditions.

# Objective - Implement `ShapeSample for CircularSector` ## Testing - The results can be verified visually. --- ## Showcase ### Boundary <img width="661" height="383" alt="Circular Sector Boundary Sampling" src="https://github.com/user-attachments/assets/a08ee2eb-9b3d-4be1-8798-9317db337513" /> ### Interior <img width="665" height="386" alt="Circular Sector Interior Sampling" src="https://github.com/user-attachments/assets/bf71ce54-e73c-414c-899d-6402c0abd9e7" />

…wing `Access` (bevyengine#20111) # Objective Improve the performance of queries using `FilteredEntityRef`, `FilteredEntityMut`, `EntityRefExcept`, and `EntityMutExcept`. In particular, this appears to speed up `bevy_animation::animate_targets` by 10% in many-foxes. `FilteredEntity(Ref|Mut)` needs to store an `Access` to determine which components may be accessed. Prior to bevyengine#15396, this required cloning the `Access` for each instance. Now, we can borrow the `Access` from the query state and make cheap pointer copies. `Entity(Ref|Mut)Except` avoided needing to clone an `Access` by calling functions on the `Bundle` trait. Unfortunately, that meant we needed to convert from a type to a `ComponentId` for every component in the bundle on every check. Now, we can do those conversions up front and pass references to an `Access`. Finally, fix a bug where `Entity(Ref|Mut)Except` would not initialize their components during `init_state`. I noticed this while updating `init_state` and fixed it while I was there. That was normally harmless because the components would be registered elsewhere, but a system like `fn system(_q1: Query<EntityMutExcept<C>>, _q2: Query<&mut C>) {}` would fail to find the `ComponentId` for `C` and not exclude it from the access for `q1`, and then panic with conflicting access from `q2`. ## Solution Change `FilteredEntityRef` and `FilteredEntityMut` to store `&'s Access` instead of `Access`, and change `EntityRefExcept` and `EntityMutExcept` to store an extra `&'s Access`. This adds the `'s` lifetime to those four types, and most changes are adding lifetimes as appropriate. Change the `WorldQuery::State` for `Entity(Ref|Mut)Except` to store an `Access` that can be borrowed from, replacing the `SmallVec<[ComponentId; 4]>` that was used only to set the query access. To support the conversions from `EntityRef` and `EntityMut`, we need to be able to create a `&'static Access` for read-all or write-all. I could not change `fn read_all_components()` to be `const` because it called the non-`const` `FixedBitSet::clear()`, so I created separate constructor functions. ## Testing Ran `cargo run --example many_foxes --features bevy/trace_tracy --release` before and after, and compared the results of `animate_targets`, since that is the only in-engine use of `EntityMutExcept` and was the motivation for creating it. Yellow is this PR, red is main: <img width="695" height="690" alt="image" src="https://github.com/user-attachments/assets/24531a3f-65bf-46d0-baa5-29ea9e56b16a" />

@janhohenheim

# Objective - Getting the closest point to a line segment is a fairly simple and useful but nontrivial operation. - @janhohenheim recently asked if we had a built-in for a similar problem. (Finding the distance, which afaik is best done by finding the closest point first, from there on it's a trivial problem given our API.) ## Solution - So I did it. ## Testing - Added 2 tests

# Objective - Cache is not reused across days as we produce too much cache and it gets cleaned by github ## Solution - create cache from main - reuse cache in other jobs --------- Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>

# Objective - Progress towards bevyengine#19887. - This example was non-trivial to port so was done as a separate PR. ## Solution - This situation is very weird. We are trying to get features of the renderer back into the main world. We use an ArcMutex to communicate between the two worlds. - We now insert the resource into both worlds, but only with Option::None. - The `RenderStartup` init system initializes the resource with the feature values populated. This does result in a "regression" where there is a single frame where the `update_status_text` system doesn't react properly, since it doesn't have the features from the render world yet. ## Testing - Ran the `occlusion_culling` example and it worked!

# Objective - Fix bevyengine#20174 ## Solution - Avoid implementing `DerefMut` for `ComponentsRegistrator` - To avoid potential breakage, expose the `any_queued_mut` and `num_queued_mut` on `ComponentsRegistrator`. These are the only methods taking `&mut self` on `Components` and for which the `DerefMut` impl could have been useful for.

# Objective - Progress towards bevyengine#19887. ## Solution - Convert `FromWorld` impls to systems in `RenderStartup`. - Add a system to conditionally add render graph edges (if a particular node exists). ## Testing - Ran the `ssr` example and it still works.

@kristoff3r

…#20195) # Objective - Progress towards bevyengine#19887. - This migration actually caught a segfault on Linux + Vulkan + llvmpipe software rendering driver + (maybe) `xvfb-run` - It seems the reason for this is that we are concurrently terminating the program (which trigger's LLVMs `atexit` handlers) while we are also compiling pipelines in parallel. It seems LLVM code is not quite multithread safe in this situation. - Thanks to @kristoff3r for figuring out this segfault! - I still have no idea why this PR triggers it and not others. ## Solution Most of this is the same as all the other `RenderStartup` migrations. - Convert FromWorld impls to RenderStartup systems. In addition, I had to 1) enable synchronous pipeline compilation, 2) disable pipelined rendering in the `ambiguity_detection` test. This ensures that 1) the render thread just blocks on pipeline compilation rather than letting it run in another thread, 2) we don't leave `App::update` until the render thread finishes. So therefore, there won't be any pipeline compilation happening by the time the test ends. ## Testing - I ran the run-examples-linux-vulkan Github action many, many times and segfaults were consistent until this PR! Now they don't seem to happen anymore.

# Objective - Part of bevyengine#20115 We don't actually need the `ScheduleGraph` in order to get the kind of a node, so lets move it to our newly created trait. ## Solution - Removed `ScheduleGraph::get_node_kind`, added `GraphNodeId::kind` instead. - Co-located `GraphNodeId` in the same file as `DiGraph`/`UnGraph`/`Graph`. - Implemented `GraphNodeId` for `SystemSetKey` for symmetry. No migration guide needed as `get_node_kind` is a private function. ## Testing Re-using current tests.

# Objective As we move more stuff to entities, it's a good idea to keep these entities quasi-private. We do not want to confuse users by having to explain everything as being an entity. This came out of bevyengine#19711. ## Solution This PR introduces the concept of internal entities, entities marked by the `Internal` component, that are filtered out by queries through `DefaultQureyFilters` and also don't show up for `World::entity_count()`. ## Testing Added a test.

# Objective - Biggest bottleneck in Solari by far is currently initial sampling for DI - Cache usage is really poor randomly sampling different lights ## Solution - Implement light tiles from https://cwyman.org/papers/hpg21_rearchitectingReSTIR.pdf - A new dispatch samples 128 blocks of 1024 samples each - Each DI workgroup randomly picks one of the 128 blocks - Each of the 32 initial samples for a thread randomly picks from within the 1024 samples in the block - This is much more cache coherent - Refactored sampling.wgsl APIs to reduce redundant data loads, execution divergence, and allow supporting light tiles and in the future specular BRDFs - Compacted LightSample and DI Reservoir struct sizes to reduce memory usage ## Testing - Needs some performance testing on both NVIDIA/AMD hardware. Please upload before/after NSight/RGP captures!

# Objective Line segments aren't meshable. ## Solution Make line segments meshable.

…vyengine#20220) # Objective - the changes done in bevyengine#19303 did not end up being necessary for bevy_camera, because i found a better split. it was still a good refactor, but lets leave it in bevy_render ## Solution - partially revert by moving the extracted file to bevy_render ## Testing - it compiles

# Objective - Fix panic when input dispatch system tries to trigger events on a despawned focused entity - Fixes bevyengine#20057 ## Solution - Added entity validity check in `dispatch_focused_input` function using `entities.contains(focused_entity)` - If the focused entity no longer exists, the focus is cleared and the event is dispatched to the window instead ## Testing - Added test `dispatch_clears_focus_when_focused_entity_despawned` that reproduces the issue scenario

# Objective - `Allows` was added as a handy tool to work with default query filters. - It wasn't in the docs though, and I had to hunt it down while reviewing bevyengine#20204. ## Solution - Add some breadcrumbs to the docs in the expected places.

# Objective - Remove an unnecessary extra `Camera2d` from one of the examples. ## Solution - I removed the `commands.spawn(Camera2d)` where it was less explicit. - Because the default camera brings a lot more thing, it is necessary to spawn it early (remove the `.after()` call) ## Testing I run the test, and the result was the same as without the change - regression passed. (Win10, GTX1050TI) Running this specific example: ``` cargo run --example sprite_scale ``` When the example starts, Gabe should run nicely.

# Objective Make it easy to efficiently count the number of entities matching a query. ## Solution Implement a `Query::count()` method. Use `as_nop()` to skip initializing the fetch state, like we do for `is_empty()` and `contains()`. If the filter is archetypal, call `size_hint()` to get the count without iterating. Otherwise, use an ordinary `count()`.

…#20234) # Objective - Cleanup unnecessary world.flush() calls in the Observer tests

…ne#20239) # Objective - the new cache action (bevyengine#20144) is currently failing on the install rust step ## Solution - Use the correct branch name

andrewzhurov · 2025-07-29T09:27:16Z

@ickshonpe 👋 Hope this won't bother you much, curious of your thoughts on this async-first approach

As arboard isn't supported on that platform, resulting in compile error.

mockersf and others added 30 commits June 29, 2025 20:36

bevy_render: fix clippy on wasm (bevyengine#19872)

01eff3e

# Objective - bevy_render has unfulfilled expected clippy lints in wasm ## Solution - Don't expect them in wasm ## Testing `cargo clippy --target wasm32-unknown-unknown -p bevy_render --no-deps -- -D warnings`

Use RenderStartup in custom_post_processing example (bevyengine#19886)

735eb88

# Objective - This example uses a FromWorld impl to initialize a resource on startup - bevyengine#19887 ## Solution - Use RenderStartup instead ## Testing - The example still works as expected

dependabot bot and others added 27 commits July 21, 2025 17:17

Make line segments meshable (bevyengine#20214)

0dd81d7

# Objective Line segments aren't meshable. ## Solution Make line segments meshable.

Observer tests contain unnecessary calls to world.flush() (bevyengine…

ed1bc13

…#20234) # Objective - Cleanup unnecessary world.flush() calls in the Observer tests

fix branch name when installing rust in cache update action (bevyengi…

f858c0d

…ne#20239) # Objective - the new cache action (bevyengine#20144) is currently failing on the install rust step ## Solution - Use the correct branch name

Merge remote-tracking branch 'bevy/main' into clipboard

9fdf4d4

andrewzhurov added 2 commits August 20, 2025 16:42

Don't include arboard dep on Android

856b939

As arboard isn't supported on that platform, resulting in compile error.

Make use of bevy_platform's conditional compilation

2b2432e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some clipboard tweaks #9

Some clipboard tweaks #9

Uh oh!

andrewzhurov commented Jul 9, 2025

Uh oh!

andrewzhurov commented Jul 29, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Some clipboard tweaks #9

Are you sure you want to change the base?

Some clipboard tweaks #9

Uh oh!

Conversation

andrewzhurov commented Jul 9, 2025

Uh oh!

andrewzhurov commented Jul 29, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants