Further bloom improvements

.github/start-wasm-example/package.json

@@ -8,7 +8,7 @@
   "author": "",
   "license": "ISC",
   "devDependencies": {
-    "@playwright/test": "^1.22.1"
+    "@playwright/test": "^1.28.1"
   },
   "dependencies": {
     "dotenv": "^16.0.1"

.github/workflows/ci.yml

@@ -108,6 +108,7 @@ jobs:
             ~/.cargo/git/db/
             target/
             crates/bevy_ecs_compile_fail_tests/target/
+            crates/bevy_reflect_compile_fail_tests/target/
           key: ${{ runner.os }}-cargo-check-compiles-${{ hashFiles('**/Cargo.toml') }}
       - uses: dtolnay/rust-toolchain@stable
         with:

.github/workflows/validation-jobs.yml

@@ -54,7 +54,7 @@ jobs:
         run: cargo install --force cargo-apk
 
       - name: Build APK
-        run: ANDROID_NDK_ROOT=$ANDROID_NDK_LATEST_HOME cargo apk build --example android_example
+        run: ANDROID_NDK_ROOT=$ANDROID_NDK_LATEST_HOME cargo apk build --package bevy-android-example
 
   run-examples-on-windows-dx12:
     runs-on: windows-latest

CONTRIBUTING.md

@@ -262,10 +262,11 @@ When in doubt about a matter of architectural philosophy, refer back to [*What w
 Once you're happy with the work and feel you're reasonably qualified to assess quality in this particular area, leave your `Approved` review on the PR.
 If you're new to GitHub, check out the [Pull Request Review documentation](https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews). Anyone can leave reviews ... no special permissions are required!
 
-There are a two main places you can check for things to review:
+There are three main places you can check for things to review:
 
-1. Pull requests on [bevy](https://github.com/bevyengine/bevy/pulls) and the [bevy-website](https://github.com/bevyengine/bevy-website/pulls) repos.
-2. [RFCs](https://github.com/bevyengine/rfcs), which need extensive thoughtful community input on their design.
+1. Pull request which are ready and in need of more reviews on [bevy](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+-label%3AS-Ready-For-Final-Review+-draft%3A%3Atrue+-label%3AS-Needs-RFC+-reviewed-by%3A%40me+-author%3A%40me)
+2. Pull requests on [bevy](https://github.com/bevyengine/bevy/pulls) and the [bevy-website](https://github.com/bevyengine/bevy-website/pulls) repos.
+3. [RFCs](https://github.com/bevyengine/rfcs), which need extensive thoughtful community input on their design.
 
 Official focus areas and work done by @cart go through this review process as well.
 Not even our project lead is exempt from reviews and RFCs!
@@ -274,6 +275,35 @@ By giving feedback on this work (and related supporting work), you can help us m
 Finally, if nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to message @cart for a Bevy org role to help us keep things tidy.
 As discussed in [*How we're organized*](#how-were-organized), this role only requires good faith and a basic understanding of our development process.
 
+### How to adopt pull requests
+
+Occasionally authors of pull requests get busy or become unresponsive, or project members fail to reply in a timely manner.
+This is a natural part of any open source project.
+To avoid blocking these efforts, these pull requests may be *adopted*, where another contributor creates a new pull request with the same content.
+If there is an old pull request that is without updates, comment to the organization whether it is appropriate to add the
+*[S-Adopt-Me](https://github.com/bevyengine/bevy/labels/S-Adopt-Me)* label, to indicate that it can be *adopted*.
+If you plan on adopting a PR yourself, you can also leave a comment on the PR asking the author if they plan on returning.
+If the author gives permission or simply doesn't respond after a few days, then it can be adopted.
+This may sometimes even skip the labeling process since at that point the PR has been adopted by you.
+
+With this label added, it's best practice to fork the original author's branch.
+This ensures that they still get credit for working on it and that the commit history is retained.
+When the new pull request is ready, it should reference the original PR in the description.
+Then notify org members to close the original.
+
+* For example, you can reference the original PR by adding the following to your PR description:
+
+`Adopted #number-original-pull-request`
+
+### Maintaining code
+
+Maintainers can merge uncontroversial pull requests that have at least two approvals (or at least one for trivial changes).
+
+These search filters show the requests that can be merged by maintainers, and those which need a final approval from @cart.
+
+1. Pulls requests which are ready for maintainers to merge without consultation: [requests to pull](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+-label%3AS-Controversial+-label%3AS-Blocked+-label%3AS-Adopt-Me+)
+2. Pull requests which need final input from @cart: [requests to verify](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+label%3AS-Controversial+)
+
 ### Contributing code
 
 Bevy is actively open to code contributions from community members.
@@ -282,6 +312,7 @@ If you're new to Bevy, here's the workflow we use:
 1. Fork the `bevyengine/bevy` repository on GitHub. You'll need to create a GitHub account if you don't have one already.
 2. Make your changes in a local clone of your fork, typically in its own new branch.
    1. Try to split your work into separate commits, each with a distinct purpose. Be particularly mindful of this when responding to reviews so it's easy to see what's changed.
+   2. Tip: [You can set up a global `.gitignore` file](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) to exclude your operating system/text editor's special/temporary files. (e.g. `.DS_Store`, `thumbs.db`, `*~`, `*.swp` or `*.swo`) This allows us to keep the `.gitignore` file in the repo uncluttered.
 3. To test CI validations locally, run the `cargo run -p ci` command. This will run most checks that happen in CI, but can take some time. You can also run sub-commands to iterate faster depending on what you're contributing:
     * `cargo run -p ci -- lints` - to run formatting and clippy
     * `cargo run -p ci -- test` - to run tests

Cargo.toml

@@ -12,9 +12,10 @@ readme = "README.md"
 repository = "https://github.com/bevyengine/bevy"
 
 [workspace]
-exclude = ["benches", "crates/bevy_ecs_compile_fail_tests"]
+exclude = ["benches", "crates/bevy_ecs_compile_fail_tests", "crates/bevy_reflect_compile_fail_tests"]
 members = [
   "crates/*",
+  "examples/android",
   "examples/ios",
   "tools/ci",
   "tools/spancmp",
@@ -31,7 +32,13 @@ default = [
   "bevy_gilrs",
   "bevy_scene",
   "bevy_winit",
-  "render",
+  "bevy_core_pipeline",
+  "bevy_pbr",
+  "bevy_gltf",
+  "bevy_render",
+  "bevy_sprite",
+  "bevy_text",
+  "bevy_ui",
   "png",
   "hdr",
   "vorbis",
@@ -42,17 +49,6 @@ default = [
 # Force dynamic linking, which improves iterative compile times
 dynamic = ["bevy_dylib"]
 
-# Rendering support
-render = [
-  "bevy_internal/bevy_core_pipeline",
-  "bevy_internal/bevy_pbr",
-  "bevy_internal/bevy_gltf",
-  "bevy_internal/bevy_render",
-  "bevy_internal/bevy_sprite",
-  "bevy_internal/bevy_text",
-  "bevy_internal/bevy_ui",
-]
-
 # Optional bevy crates
 bevy_animation = ["bevy_internal/bevy_animation"]
 bevy_asset = ["bevy_internal/bevy_asset"]
@@ -1362,7 +1358,7 @@ wasm = true
 # Tools
 [[example]]
 name = "scene_viewer"
-path = "examples/tools/scene_viewer.rs"
+path = "examples/tools/scene_viewer/main.rs"
 
 [package.metadata.example.scene_viewer]
 name = "Scene Viewer"
@@ -1442,6 +1438,16 @@ description = "Illustrates creating and updating a button"
 category = "UI (User Interface)"
 wasm = true
 
+[[example]]
+name = "window_fallthrough"
+path = "examples/ui/window_fallthrough.rs"
+
+[package.metadata.example.window_fallthrough]
+name = "Window Fallthrough"
+description = "Illustrates how to access `winit::window::Window`'s `hittest` functionality."
+category = "UI (User Interface)"
+wasm = false
+
 [[example]]
 name = "font_atlas_debug"
 path = "examples/ui/font_atlas_debug.rs"
@@ -1597,31 +1603,13 @@ description = "Demonstrates resizing and responding to resizing a window"
 category = "Window"
 wasm = true
 
-# Android
-[[example]]
-crate-type = ["cdylib"]
-name = "android_example"
-path = "examples/android/android.rs"
-
-[package.metadata.example.android_example]
-hidden = true
-
-[package.metadata.android]
-package = "org.bevyengine.example"
-apk_name = "bevyexample"
-assets = "assets"
-resources = "assets/android-res"
-build_targets = ["aarch64-linux-android", "armv7-linux-androideabi"]
-
-[package.metadata.android.sdk]
-target_sdk_version = 31
-
-[package.metadata.android.application]
-icon = "@mipmap/ic_launcher"
-label = "Bevy Example"
-
 [profile.wasm-release]
 inherits = "release"
 opt-level = "z"
 lto = "fat"
 codegen-units = 1
+
+[profile.stress-test]
+inherits = "release"
+lto = "fat"
+panic = "abort"

crates/bevy_app/src/app.rs

@@ -73,6 +73,8 @@ pub struct App {
     sub_apps: HashMap<AppLabelId, SubApp>,
     plugin_registry: Vec<Box<dyn Plugin>>,
     plugin_name_added: HashSet<String>,
+    /// A private marker to prevent incorrect calls to `App::run()` from `Plugin::build()`
+    is_building_plugin: bool,
 }
 
 impl Debug for App {
@@ -107,9 +109,7 @@ impl Default for App {
         #[cfg(feature = "bevy_reflect")]
         app.init_resource::<AppTypeRegistry>();
 
-        app.add_default_stages()
-            .add_event::<AppExit>()
-            .add_system_to_stage(CoreStage::Last, World::clear_trackers);
+        app.add_default_stages().add_event::<AppExit>();
 
         #[cfg(feature = "bevy_ci_testing")]
         {
@@ -138,6 +138,7 @@ impl App {
             sub_apps: HashMap::default(),
             plugin_registry: Vec::default(),
             plugin_name_added: Default::default(),
+            is_building_plugin: false,
         }
     }
 
@@ -150,20 +151,31 @@ impl App {
         #[cfg(feature = "trace")]
         let _bevy_frame_update_span = info_span!("frame").entered();
         self.schedule.run(&mut self.world);
+
         for sub_app in self.sub_apps.values_mut() {
             (sub_app.runner)(&mut self.world, &mut sub_app.app);
+            sub_app.app.world.clear_trackers();
         }
+
+        self.world.clear_trackers();
     }
 
     /// Starts the application by calling the app's [runner function](Self::set_runner).
     ///
     /// Finalizes the [`App`] configuration. For general usage, see the example on the item
     /// level documentation.
+    ///
+    /// # Panics
+    ///
+    /// Panics if called from `Plugin::build()`, because it would prevent other plugins to properly build.
     pub fn run(&mut self) {
         #[cfg(feature = "trace")]
         let _bevy_app_run_span = info_span!("bevy_app").entered();
 
         let mut app = std::mem::replace(self, App::empty());
+        if app.is_building_plugin {
+            panic!("App::run() was called from within Plugin::Build(), which is not allowed.");
+        }
         let runner = std::mem::replace(&mut app.runner, Box::new(run_once));
         (runner)(app);
     }
@@ -856,7 +868,9 @@ impl App {
                 plugin_name: plugin.name().to_string(),
             })?;
         }
+        self.is_building_plugin = true;
         plugin.build(self);
+        self.is_building_plugin = false;
         self.plugin_registry.push(plugin);
         Ok(self)
     }
@@ -1103,4 +1117,16 @@ mod tests {
     fn can_add_twice_the_same_plugin_not_unique() {
         App::new().add_plugin(PluginD).add_plugin(PluginD);
     }
+
+    #[test]
+    #[should_panic]
+    fn cant_call_app_run_from_plugin_build() {
+        struct PluginRun;
+        impl Plugin for PluginRun {
+            fn build(&self, app: &mut crate::App) {
+                app.run();
+            }
+        }
+        App::new().add_plugin(PluginRun);
+    }
 }