# Objective

This crate is needed if we want to successfully publish other Bevy
crates (hint: we do!)

…t_loading example between 0.12.1 and 0.13.0 (bevyengine#11935)

# Objective

- revert a single-line change made to `examples/asset/asset_loading`
example between `v0.12.1` release and `v0.13.0` release which resulted
in a too-bright, washed-out rendering

## Solution

- reverted the changes made to this example between `v0.12.1` and
`v0.13.0`

# Objective

- Fixes bevyengine#11960
- The compilation of `bevy_core_pipeline` failed with the `dds` feature
enabled

## Solution

- Enable the `dds` feature of `bevy_render` when enabling it for
`bevy_core_pipeline`

# Objective

Fixes bevyengine#11964.

## Solution

Adds the `serde` feature to `bitflags` for `bevy_render`. This makes
`bevy_render` compile correctly when used alone.

---

## Changelog

- Fixed an issue where depending on `bevy_render` alone would fail to
compile.

# Objective

* Fixes bevyengine#11932 (performance impact when stepping is disabled)

## Solution

The `Option<FixedBitSet>` argument added to `ScheduleExecutor::run()` in
bevyengine#8453 caused a measurable performance impact even when stepping is
disabled. This can be seen by the benchmark of running `Schedule:run()`
on an empty schedule in a tight loop
(bevyengine#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing
the argument
`ScheduleExecutor::run()` from `Option<FixedBitSet>` to
`Option<&FixedBitSet>`. The down-side of this change is that
`Schedule::run()` now takes about 6% longer (3.7319 ms vs 3.9855ns) when
stepping is enabled

---

## Changelog
* Change `ScheduleExecutor::run()` `_skipped_systems` from
`Option<FixedBitSet>` to `Option<&FixedBitSet>`
* Added a few benchmarks to measure `Schedule::run()` performance with
various executors

…engine#11968)

# Objective

If multiple cameras render to the same target with MSAA enabled, only
the first and the last camera output will appear in the final output*.
This is because each camera maintains a separate flag to track the
active main texture. The first camera renders to texture A and all
subsequent cameras first write-back from A and then render into texture
B. Hence, camera 3 onwards will overwrite the work of the previous
camera.

\* This would manifest slightly differently if there were other calls to
post_process_write() in a more complex setup.

The is a functional regression from Bevy 0.12.

## Solution

The flag which tracks the active main texture should be shared between
cameras with the same `NormalizedRenderTarget`. Add the
`Arc<AtomicUsize>` to the existing per-target cache.

# Objective

- The file asset source currently creates the `imported_assets/Default`
directory with relative path, which leads to wrongly created directories
when the executable is run with a working directory different from the
project root.

## Solution

- Use the full path instead.

- The 3D Lighting example is meant to show using multiple lights in the
same scene.
- It currently looks very dark. (See [this
image](https://github.com/bevyengine/bevy-website/pull/1023/files/4fdb1455d5a3371d69db32b036e38731342b48de#r1494653511).)
- Resetting the physical camera properties sets the shutter speed to 1 /
125, even though it initially starts at 1 / 100.

- Increase the intensity of all 3 lights in the example.
  - Now it is much closer to the example in Bevy 0.12.
- I had to remove the comment explaining the lightbulb equivalent of the
intensities because I don't know how it was calculated. Does anyone know
what light emits 100,000 lumens?
- Set the initial shutter speed to 1 / 125.

Before:

<img width="1392" alt="before"
src="https://github.com/bevyengine/bevy/assets/59022059/ac353e02-58e9-4661-aa6d-e5fdf0dcd2f6">

After:

<img width="1392" alt="after"
src="https://github.com/bevyengine/bevy/assets/59022059/4ff0beb6-0ced-4fb2-a953-04be2c77f437">

---------

Co-authored-by: Alice Cecile <[email protected]>

# Objective

- Fixes bevyengine#12001.
- Note this PR doesn't change any feature flags, however flaky the issue
revealed they are.

## Solution

- Use `FromReflect` to convert proxy types to concrete ones in
`ReflectSerialize::get_serializable`.
- Use `get_represented_type_info() -> type_id()` to get the correct type
id to interact with the registry in
`bevy_reflect::serde::ser::get_serializable`.

---

## Changelog

- Registering `ReflectSerialize` now imposes additional `FromReflect`
and `TypePath` bounds.

## Migration Guide

- If `ReflectSerialize` is registered on a type, but `TypePath` or
`FromReflect` implementations are omitted (perhaps by
`#[reflect(type_path = false)` or `#[reflect(from_reflect = false)]`),
the traits must now be implemented.

---------

Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Gino Valente <[email protected]>

- bevyengine#11868 changed the lighting system, forcing lights to increase their
intensity. The PR fixed most examples, but missed a few. These I later
caught in bevyengine/bevy-website#1023.
- Related: bevyengine#11982, bevyengine#11981.
- While there, I noticed that the spotlight example could use a few easy
improvements.

- Increase lighting in `skybox`, `spotlight`, `animated_transform`, and
`gltf_skinned_mesh`.
- Improve spotlight example.
- Make ground plane move with cubes, so they don't phase into each
other.
  - Batch spawn cubes.
  - Add controls text.
  - Change controls to allow rotating around spotlights.

Before:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/8ba00d74-6d68-4414-97a8-28afb8305570">

After:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/ad15c471-6979-4dda-9889-9189136d8404">

Before:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/53f966de-acf3-46b8-8299-0005c4cb8da0">

After:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/05c73c1e-0739-4226-83d6-e4249a9105e0">

Before:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/6d7d4ea0-e22e-42a5-9905-ea1731d474cf">

After:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/f1ee08d6-d17a-4391-91a6-d903b9fbdc3c">

Before:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/547569a6-d13b-4fe0-a8c1-e11f02c4f9a2">

After:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/34517aba-09e4-4e9b-982a-a4a8b893c48a">

---

- Increased lighting in `skybox`, `spotlight`, `animated_transform`, and
`gltf_skinned_mesh` examples.
- Improved usability of `spotlight` example.

# Objective

- Globals are supposed to be available in vertex shader but that was
mistakenly removed in 0.13

## Solution

- Configure the visibility of the globals correctly

Fixes bevyengine#12015

…_id` (bevyengine#12030)

## Objective

Always have `some_system.into_system().type_id() ==
some_system.into_system_set().system_type().unwrap()`.

System sets have a `fn system_type() -> Option<TypeId>` that is
implemented by `SystemTypeSet` to returning the TypeId of the system's
function type. This was implemented in
bevyengine#7715 and is used in
`bevy_mod_debugdump` to handle `.after(function)` constraints.

Back then, `System::type_id` always also returned the type id of the
function item, not of `FunctionSystem<M, F>`.

bevyengine#11728 changes the behaviour of
`System::type_id` so that it returns the id of the
`FunctionSystem`/`ExclusiveFunctionSystem` wrapper, but it did not
change `SystemTypeSet::system_type`, so doing the lookup breaks in
`bevy_mod_debugdump`.

## Solution

Change `IntoSystemSet` for functions to return a
`SystemTypeSet<FunctionSystem>` /
`SystemTypeSet<ExclusiveFunctionSystem>` instead of `SystemTypeSet<F>`.

# Objective

Fixes bevyengine#11944

## Solution

bevyengine#11600 made an incorrect assumption on what `UiImageSize` does, removing
its usage in slicing fixes the problem

…evyengine#12052)

This PR closes bevyengine#11978

# Objective

Fix rendering on iOS Simulators.

iOS Simulator doesn't support the capability CUBE_ARRAY_TEXTURES, since
0.13 this started to make iOS Simulator not render anything with the
following message being outputted:

```
2024-02-19T14:59:34.896266Z ERROR bevy_render::render_resource::pipeline_cache: failed to create shader module: Validation Error

Caused by:
    In Device::create_shader_module
    
Shader validation error: 


    Type [40] '' is invalid
    Capability Capabilities(CUBE_ARRAY_TEXTURES) is required
```

## Solution

- Split up NO_ARRAY_TEXTURES_SUPPORT into both NO_ARRAY_TEXTURES_SUPPORT
and NO_CUBE_ARRAY_TEXTURES_SUPPORT and correctly apply
NO_ARRAY_TEXTURES_SUPPORT for iOS Simulator using the cfg flag
introduced in bevyengine#10178.

---

## Changelog

### Fixed
- Rendering on iOS Simulator due to missing CUBE_ARRAY_TEXTURES support.

---------

Co-authored-by: Sam Pettersson <[email protected]>

# Objective

- Some properties of public types are private but sometimes it's useful
to be able to set those

## Solution

- Make more stuff pub

---

## Changelog

- `MaterialBindGroupId` internal id is now pub and added a new()
constructor
- `ExtractedPointLight` and `ExtractedDirectionalLight` properties are
now all pub

---------

Co-authored-by: James Liu <[email protected]>

…2051)

# Objective

- Fixes bevyengine#11977 - user defined shaders don't work in wasm
- After investigation, it won't work if the shader is not yet available
when compiling the pipeline on all platforms, for example if you load
many assets

## Solution

- Set the pipeline state to queued when it errs waiting for the shader
so that it's retried

… errors. (bevyengine#12046)

# Objective

Improve code quality and prevent bugs.

## Solution

I removed the unnecessary wildcards from `<LogPlugin as Plugin>::build`.

I also changed the warnings that would occur if the subscriber/logger
was already set into errors.

# Objective

Fixes Skyboxes on WebGL, which broke in Bevy 0.13 due to the addition of
the `brightness` uniform, when previously the skybox pipeline only had
view and global uniforms.

```ignore
panicked at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.1/src/backend/wgpu_core.rs:3009:5:
wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `skybox_pipeline`
    In the provided shader, the type given for group 0 binding 3 has a size of 4. As the device does not support `DownlevelFlags::BUFFER_BINDINGS_NOT_16_BYTE_ALIGNED`, the type must have a size that is a multiple of 16 bytes.
```

It would be nice if this could be backported to a 0.13.1 patch as well
if possible. I'm needing to rely on my own fork for now.

## Solution

Similar to the Globals uniform solution here:


https://github.com/bevyengine/bevy/blob/d31de3f1398080661a83a04dcbdd31a7ee9fa76e/crates/bevy_render/src/globals.rs#L59-L60

I've added 3 conditional fields to `SkyboxUniforms`.

# Objective

Since bevyengine#9822, `SimpleExecutor` panics when an automatic sync point is
inserted:

```rust
let mut sched = Schedule::default();
sched.set_executor_kind(ExecutorKind::Simple);
sched.add_systems((|_: Commands| (), || ()).chain());
sched.run(&mut World::new());
```
```
System's param_state was not found. Did you forget to initialize this system before running it?
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_ecs::schedule::executor::apply_deferred`!
```

## Solution

Don't try to run the `apply_deferred` system.

# Objective

- Make `GizmoConfigStore` play well with reflection-based workflows like
editors.

## Solution

- `#[derive(Reflect)]` and call `.register_type()`.

# Objective

- Fixes bevyengine#12057 

## Solution

- Add a note about memory management in Wasm

# Objective

- Fixes bevyengine#10826
- Fixes bevyengine#9615

## Solution

- Early-out when components are missing.

…2055)

# Objective

- Bevy fails to change screen orientation on iOS
```
Main Thread Checker: UI API called on a background thread: -[UIView layer]
PID: 37669, TID: 13872050, Thread name: Compute Task Pool (1), Queue name: com.apple.root.default-qos.overcommit, QoS: 0
Backtrace:
4   bevy_mobile_example                 0x0000000102cf92b8 _ZN60_$LT$$LP$$RP$$u20$as$u20$objc..message..MessageArguments$GT$6invoke17h8944e3d8ee34f15fE + 64
5   bevy_mobile_example                 0x0000000102c46358 _ZN4objc7message8platform15send_unverified17h667844cebe2d7931E + 132
6   bevy_mobile_example                 0x0000000102bcbd6c _ZN8wgpu_hal5metal7surface100_$LT$impl$u20$wgpu_hal..Surface$LT$wgpu_hal..metal..Api$GT$$u20$for$u20$wgpu_hal..metal..Surface$GT$9configure17h8a6af0f24cec1328E + 1548
7   bevy_mobile_example                 0x000000010279be50 _ZN9wgpu_core6device6global52_$LT$impl$u20$wgpu_core..global..Global$LT$G$GT$$GT$17surface_configure17h52709bbb3b3f0ff1E + 2792
8   bevy_mobile_example                 0x000000010287aacc _ZN84_$LT$wgpu..backend..wgpu_core..ContextWgpuCore$u20$as$u20$wgpu..context..Context$GT$17surface_configure17h54077b9f040286a4E + 508
9   bevy_mobile_example                 0x00000001028904b4 _ZN47_$LT$T$u20$as$u20$wgpu..context..DynContext$GT$17surface_configure17hfd6a0ac5a67a8f02E + 256
10  bevy_mobile_example                 0x00000001028a1870 _ZN4wgpu7Surface9configure17h97bf7dbd54220473E + 148
11  bevy_mobile_example                 0x0000000101fdc7cc _ZN11bevy_render8renderer13render_device12RenderDevice17configure_surface17h6853eab840b53e07E + 56
12  bevy_mobile_example                 0x000000010228eb64 _ZN11bevy_render4view6window15prepare_windows17hf6f8b3c93ba189b8E + 3248
13  bevy_mobile_example                 0x0000000102169eb8 _ZN4core3ops8function5FnMut8call_mut17h53ae762930afec98E + 192
14  bevy_mobile_example                 0x0000000101e46a80 _ZN4core3ops8function5impls79_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$8call_mut17h5789c37c5983ce4cE + 208
15  bevy_mobile_example                 0x0000000101e936e4 _ZN152_$LT$Func$u20$as$u20$bevy_ecs..system..function_system..SystemParamFunction$LT$fn$LP$F0$C$F1$C$F2$C$F3$C$F4$C$F5$C$F6$C$F7$RP$$u20$.$GT$$u20$Out$GT$$GT$3run10call_inner17h4ea44d3456146151E + 220
16  bevy_mobile_example                 0x0000000101e4683c _ZN152_$LT$Func$u20$as$u20$bevy_ecs..system..function_system..SystemParamFunction$LT$fn$LP$F0$C$F1$C$F2$C$F3$C$F4$C$F5$C$F6$C$F7$RP$$u20$.$GT$$u20$Out$GT$$GT$3run17h6515ba9e61bb4d59E + 204
17  bevy_mobile_example                 0x0000000101e7f99c _ZN120_$LT$bevy_ecs..system..function_system..FunctionSystem$LT$Marker$C$F$GT$$u20$as$u20$bevy_ecs..system..system..System$GT$10run_unsafe17h78999ea2add1da26E + 212
18  bevy_mobile_example                 0x0000000103b4ef60 _ZN8bevy_ecs8schedule8executor14multi_threaded21MultiThreadedExecutor17spawn_system_task28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17hb2572f7968d8618eE + 48
19  bevy_mobile_example                 0x0000000103b5bc9c _ZN4core3ops8function6FnOnce9call_once17h4cfa9d5c488566d4E + 16
20  bevy_mobile_example                 0x0000000103b2d58c _ZN115_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$9call_once17he61d5557ff370a2cE + 40
21  bevy_mobile_example                 0x0000000103b34548 _ZN3std9panicking3try7do_call17hb9ad087e1a06eb39E + 72
22  bevy_mobile_example                 0x0000000103b351bc __rust_try + 32
23  bevy_mobile_example                 0x0000000103b33a30 _ZN3std9panicking3try17hdebf82084f4342b0E + 76
24  bevy_mobile_example                 0x0000000103c4aedc _ZN3std5panic12catch_unwind17h7e60b22a0a18032eE + 12
25  bevy_mobile_example                 0x0000000103b4ea78 _ZN8bevy_ecs8schedule8executor14multi_threaded21MultiThreadedExecutor17spawn_system_task28_$u7b$$u7b$closure$u7d$$u7d$17h1af950387501b795E + 148
26  bevy_mobile_example                 0x0000000103b2cfa0 _ZN100_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h1258e4bf3dbe2fd8E + 48
```

## Solution

- run surface configuration on the main thread on iOS

## Migration Guide

System `need_new_surfaces` has been renamed `need_surface_configuration`
and now also configure the surfaces on window creation or resizing

This PR unpins `web-sys` so that unrelated projects that have
`bevy_render` in their workspace can finally update their `web-sys`.
More details in and fixes bevyengine#12246.

* Update `wgpu` from 0.19.1 to 0.19.3.
* Remove the `web-sys` pin.
* Update docs and wasm helper to remove the now-stale
`--cfg=web_sys_unstable_apis` Rust flag.

---

Updated `wgpu` to v0.19.3 and removed `web-sys` pin.

…ne#12197)

Hi, this is a minimal implementation of bevyengine#12159. I wasn't sure if the
`EventLoopProxy` should be wrapped somewhat to make it more explicit.

Minimal implementation of bevyengine#12159
When using `UpdateMode::Reactive` it is currently not possible to
request a redraw when a long running task is finished or an external
source has new data.

This makes the following possible which will then run an app update once

``` rust
// EventLoopProxy is Send on most architectures
// The EventLoopProxy can also be saved in a thread local for WASM or a static in other architecturecs
pub fn example(proxy: NonSend<EventLoopProxy<()>>) {
    let clone: EventLoopProxy<()> = proxy.clone();
    thread::spawn(move || {
        // do long work
        clone.send_event(());
    });
}
```

By using the EventLoopProxy one can manually send events from external
threads to the event loop as `UserEvent`s.
This simply sets redraw_requested when a `UserEvent` is received.

- Added the ability to request a redraw from an external source

---------

Co-authored-by: Kellner, Robin <[email protected]>

# Objective

Fixes bevyengine#12126

Notably this does not appear to fix the console error spam that appears
to be coming from winit, only the performance bug that occurs when
tabbing out and back into the game.

## Solution

The winit event loop starts out as `ControlFlow::Wait` by default. When
switching to `UpdateMode::Reactive` or `UpdateMode::ReactiveLowPower`,
we repeatedly update this to `ControlFlow::WaitUntil(next)`. When
switching back to `UpdateMode::Continuous`, the event loop is
erroneously stuck at the latest `ControlFlow::WaitUntil(next)` that was
issued.

I also changed how we handle `Event::NewEvents` since the `StartCause`
already tells us enough information to make that decision. This came
about my debugging and I left it in as an improvement.

… allowing layout to be calculated (bevyengine#12268)

# Objective

- Fixes bevyengine#12255

Still needs confirming what the consequences are from having camera
viewport nodes live on the root of the taffy tree.

## Solution

To fix calculating the layouts for UI nodes we need to cleanup the
children previously set whenever `TargetCamera` is updated. This also
maintains a list of taffy camera nodes and cleans them up when removed.

---

## Changelog

Fixed bevyengine#12255

## Migration Guide

changes affect private structs/members so shouldn't need actions by
engine users.

- Avoid version mismatch
- When cpal updates oboe in a patch release, this breaks android support
for Bevy

- Use the same version of oboe as cpal by relying on it to re-export the
feature

…rride` (bevyengine#12321)

# Objective

Fixes bevyengine#12282.

## Solution

Use `set_scale_factor_override` in `with_scale_factor_override`.

…ity (bevyengine#12342)

# Objective

- Fix slightly wrong logic from bevyengine#11442
- Directional lights should not have a near clip plane

## Solution

- Push near clip out to infinity, so that the frustum normal is still
available if its needed for whatever reason in shader
- also opportunistically nabs a typo

…bevyengine#12355)

# Objective

Fixes bevyengine#12353

When only `webp` was selected, `ImageLoader` would not be initialized.

That is, users using `default-features = false` would need to add `png`
or `bmp` or something in addition to `webp` in order to use `webp`.

This was also the case for `pnm`. 

## Solution

Add `webp` and `pnm` to the list of features that trigger the
initialization of `ImageLoader`.

- With the recent lighting changes, the default configuration in the
`bloom_3d` example is less clear what bloom actually does
- See [this
screenshot](https://github.com/bevyengine/bevy-website/pull/1023/files/4fdb1455d5a3371d69db32b036e38731342b48de#r1494648414)
for a comparison.
- `bloom_3d` additionally uses a for-loop to spawn the spheres, which
can be turned into `commands::spawn_batch` call.
- The text is black, which is difficult to see on the gray background.

- Increase emmisive values of materials.
- Set text to white.

Before:

<img width="1392" alt="before"
src="https://github.com/bevyengine/bevy/assets/59022059/757057ad-ed9f-4eed-b135-8e2032fcdeb5">

After:

<img width="1392" alt="image"
src="https://github.com/bevyengine/bevy/assets/59022059/3f9dc7a8-94b2-44b9-8ac3-deef1905221b">

---------

Co-authored-by: Alice Cecile <[email protected]>

…_rotation_translation` (bevyengine#12375)

# Objective

Fixes bevyengine#12360.

## Solution

Normalize the rotation `Quat` in `sphere`.

# Objective

fix occasional crash from commands.insert when quickly spawning and
despawning skinned/morphed meshes
 
## Solution

use `try_insert` instead of `insert`. if the entity is deleted we don't
mind failing to add the `NoAutomaticBatching` marker.

…evyengine#12395)

# Objective

fix bevyengine#12007

## Solution

when node size is zero on either axis, set
`RelativeCursorPosition::normalized` to None.

# Objective

`System<f32>` currently does not implement `Eq` even though it should

## Solution

Manually implement `Eq` like other traits are manually implemented

# Objective

Fixes bevyengine#12064

## Solution

Prior to bevyengine#11326, the "global physical" translation of text was rounded.

After bevyengine#11326, only the "offset" is being rounded.

This moves things around so that the "global translation" is converted
to physical pixels, rounded, and then converted back to logical pixels,
which is what I believe was happening before / what the comments above
describe.

## Discussion

This seems to work and fix an obvious mistake in some code, but I don't
fully grok the ui / text pipelines / math here.

## Before / After and test example

<details>
<summary>Expand Code</summary>

```rust
use std::f32::consts::FRAC_PI_2;

use bevy::prelude::*;
use bevy_internal::window::WindowResolution;

const FONT_SIZE: f32 = 25.0;
const PADDING: f32 = 5.0;

fn main() {
    App::new()
        .add_plugins(
            DefaultPlugins.set(WindowPlugin {
                primary_window: Some(Window {
                    resolution: WindowResolution::default().with_scale_factor_override(1.0),
                    ..default()
                }),
                ..default()
            }),
            //.set(ImagePlugin::default_nearest()),
        )
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(Camera2dBundle::default());

    let font = asset_server.load("fonts/FiraSans-Bold.ttf");

    for x in [20.5, 140.0] {
        for i in 1..10 {
            text(
                &mut commands,
                font.clone(),
                x,
                (FONT_SIZE + PADDING) * i as f32,
                i,
                Quat::default(),
                1.0,
            );
        }
    }

    for x in [450.5, 700.0] {
        for i in 1..10 {
            text(
                &mut commands,
                font.clone(),
                x,
                ((FONT_SIZE * 2.0) + PADDING) * i as f32,
                i,
                Quat::default(),
                2.0,
            );
        }
    }

    for y in [400.0, 600.0] {
        for i in 1..10 {
            text(
                &mut commands,
                font.clone(),
                (FONT_SIZE + PADDING) * i as f32,
                y,
                i,
                Quat::from_rotation_z(FRAC_PI_2),
                1.0,
            );
        }
    }
}

fn text(
    commands: &mut Commands,
    font: Handle<Font>,
    x: f32,
    y: f32,
    i: usize,
    rot: Quat,
    scale: f32,
) {
    let text = (65..(65 + i)).map(|a| a as u8 as char).collect::<String>();

    commands.spawn(TextBundle {
        style: Style {
            position_type: PositionType::Absolute,
            left: Val::Px(x),
            top: Val::Px(y),
            ..default()
        },
        text: Text::from_section(
            text,
            TextStyle {
                font,
                font_size: FONT_SIZE,
                ..default()
            },
        ),
        transform: Transform::from_rotation(rot).with_scale(Vec2::splat(scale).extend(1.)),
        ..default()
    });
}
```

</details>

Open both images in new tabs and swap back and forth. Pay attention to
the "A" and "ABCD" lines.

<details>
<summary>Before</summary>

<img width="640" alt="main3"
src="https://github.com/bevyengine/bevy/assets/200550/248d7a55-d06d-433f-80da-1914803c3551">

</details>

<details>
<summary>After</summary>

<img width="640" alt="pr3"
src="https://github.com/bevyengine/bevy/assets/200550/26a9d292-07ae-4af3-b035-e187b2529ace">

</details>

---------

Co-authored-by: François Mockers <[email protected]>

…vyengine#12428)

# Objective

To have a user level workaround for bevyengine#12237.

## Solution

Workaround to the problem is described in:
bevyengine#12237 (comment)

## Changelog

### Changed

- `CreateWindowParams` type and `create_windows` system from
`bevy_winit` is now public, which allows library authors and game
developers to manually trigger window creation when needed.

# Objective

- Addresses bevyengine#12462
- When we serialize an enum, deserialize it, then reserialize it, the
correct variant should be selected.

## Solution

- Change `dynamic_enum.set_variant` to
`dynamic_enum.set_variant_with_index` in `EnumVisitor`

# Objective

The `example-showcase` command is failing to run.

```
 cargo run --release -p example-showcase -- run --screenshot --in-ci                                  
    Updating crates.io index
   Compiling example-showcase v0.14.0-dev (/Users/robparrett/src/bevy/tools/example-showcase)
    Finished release [optimized] target(s) in 2.59s
     Running `target/release/example-showcase run --screenshot --in-ci`
$ git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch
error: patch failed: crates/bevy_winit/src/winit_config.rs:29
error: crates/bevy_winit/src/winit_config.rs: patch does not apply
thread 'main' panicked at tools/example-showcase/src/main.rs:203:18:
called `Result::unwrap()` on an `Err` value: command exited with non-zero code `git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch`: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

## Solution

Update `remove-desktop-app-mode.patch`.

fix bevyengine#12344

use existing machinery in track_assets to determine if the asset is
unused before firing Asset::Unused event

~~most extract functions use `AssetEvent::Removed` to schedule deletion
of render world resources. `RenderAssetPlugin` was using
`AssetEvent::Unused` instead.
`Unused` fires when the last strong handle is dropped, even if a new one
is created. `Removed` only fires when a new one is not created.
as far as i can see, `Unused` is the same as `Removed` except for this
"feature", and that it also fires early if all handles for a loading
asset are dropped (`Removed` fires after the loading completes). note
that in that case, processing based on `Loaded` won't have been done
anyway.
i think we should get rid of `Unused` completely, it is not currently
used anywhere (except here, previously) and i think using it is probably
always a mistake.
i also am not sure why we keep loading assets that have been dropped
while loading, we should probably drop the loader task as well and
remove immediately.~~

… event loop

# Objective

This PR fixes bevyengine#12125

## Solution

The logic in this PR was borrowed from gloo-net and essentially probes
the global Javascript context to see if we are in a window or a worker
before calling `fetch_with_str`.

---------

Co-authored-by: Zachary Harrold <[email protected]>

# Objective

Fix the regression for Root Node's Layout behavior introduced in
bevyengine#12268

- Add regression test for Root Node Layout's behaving as they did before
0.13.1
- Restore pre 0.13.1 Root Node Layout behavior (fixes
bevyengine#12624)

## Solution

This implements [@nicoburns suggestion
](https://discord.com/channels/691052431525675048/743663673393938453/1221593626476548146),
where instead of adding the camera to the taffy node tree, we revert
back to adding a new "parent" node for each root node while maintaining
their relationship with the camera.

> If you can do the ecs change detection to move the node to the correct
Taffy instance for the camera then you should also be able to move it to
a `Vec` of root nodes for that camera.

---

## Changelog

Fixed bevyengine#12624 - Restores pre
0.13.1 Root Node Layout behavior

## Migration Guide

If you were affected by the 0.13.1 regression and added `position_type:
Absolute` to all your root nodes you might be able to reclaim some LOC
by removing them now that the 0.13 behavior is restored.

# Objective

- Example `mesh2d_manual` crashes in wasm/webgl2, as reported in
bevyengine/bevy-website#1123 (comment)
```
wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 1, Gl)>`
    In a set_push_constant command
    Provided push constant is for stage(s) ShaderStages(VERTEX), however the pipeline layout has no push constant range for the stage(s) ShaderStages(VERTEX)
```

## Solution

- Properly declare the push constant as in
https://github.com/bevyengine/bevy/blob/4508077297a92295d8b6fb6b07a63b547deac1e0/crates/bevy_sprite/src/mesh2d/mesh.rs#L514-L524

# Objective
Fix bevyengine#12728. Fix unsoundnesss from unhandled null characters in Android
logs.

## Solution
Use `CString` instead of using formatted Strings. Properly document the
safety invariants of the FFI call.

# Objective

Fix crashing on Linux with latest stable Nvidia 550 driver when
resizing. The crash happens at startup with some setups.

Fixes bevyengine#12199

I think this would be nice to get into 0.13.1

## Solution

Ignore `wgpu::SurfaceError::Outdated` always on this platform+driver.

It looks like Nvidia considered the previous behaviour of not returning
this error a bug:
"Fixed a bug where vkAcquireNextImageKHR() was not returning
VK_ERROR_OUT_OF_DATE_KHR when it should with WSI X11 swapchains"
(https://www.nvidia.com/Download/driverResults.aspx/218826/en-us/)

What I gather from this is that the surface was outdated on previous
drivers too, but they just didn't report it as an error. So behaviour
shouldn't change.

In the issue conversation we experimented with calling `continue` when
this error happens, but I found that it results in some small issues
like bevy_egui scale not updating with the window sometimes. Just doing
nothing seems to work better.

## Changelog

- Fixed crashing on Linux with Nvidia 550 driver when resizing the
window

## Migration Guide

---------

Co-authored-by: James Liu <[email protected]>

…evyengine#12862)

# Objective

See gfx-rs/wgpu#5488 for context and
rationale.

## Solution

- Disables `wgpu::Features::RAY_QUERY` and
`wgpu::Features::RAY_TRACING_ACCELERATION_STRUCTURE` by default. They
must be explicitly opted into now.

---

## Changelog

- Disables `wgpu::Features::RAY_QUERY` and
`wgpu::Features::RAY_TRACING_ACCELERATION_STRUCTURE` by default. They
must be explicitly opted into now.

## Migration Guide

- If you need `wgpu::Features::RAY_QUERY` or
`wgpu::Features::RAY_TRACING_ACCELERATION_STRUCTURE`, enable them
explicitly using `WgpuSettings::features`

* fix: wait elapsed true due to window events

* fix: reacting to window events

* refactor: cleanup uneeded check

* fix: 1 frame delay when changing WinitSettings

* chore: comment