Screenshot::image() no longer works with off-screen textures not attached to a Camera's RenderTarget #25215

Activity

1. MisteryDust

   added

   C-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behavior

   S-Needs-TriageThis issue needs to be labelledThis issue needs to be labelled

   on Jul 29, 2026
2. mansiverma897993

   added 2 commits that reference this issue on Jul 30, 2026

   Fix Screenshot::image() for images not rendered to by a camera

   ...

   This issue will close once commit f589542 is merged into the 'main' branch.

   f589542

   Fix Screenshot::image() for images not rendered to by a camera

   ...

   This issue will close once commit 814924e is merged into the 'main' branch.

   814924e
3. JaySpruce

   added

   A-RenderingDrawing game state to the screenDrawing game state to the screen

   S-Needs-InvestigationThis issue requires detective work to figure out what's going wrongThis issue requires detective work to figure out what's going wrong

   and removed

   S-Needs-TriageThis issue needs to be labelledThis issue needs to be labelled

   on Aug 6, 2026
4. github-project-automation

   moved this to Needs SME Triage in Renderingon Aug 6, 2026
5. github-project-automation

   added this to Renderingon Aug 6, 2026
6. AIMentalModel commented on Sep 28, 2026

   

   AIMentalModel

   on Sep 28, 2026

   More actions

   I can reproduce a broader form of this on 0.19 — in my case the output is all-black even when the texture is attached to a camera's RenderTarget::Image, and Screenshot::primary_window() is equally affected.

   Environment

   • bevy 0.19.0/0.19.1 (wgpu 29); reproduced with default features and with a minimal feature set
   • macOS 26.6.2 (kernel 25.6.0), Apple M1, Metal: AdapterInfo { name: "Apple M1", device_type: IntegratedGpu, backend: Metal }
   • Reproduced in all of: visible window, visible: false window, and headless (WinitPlugin disabled + ScheduleRunnerPlugin)

   Key evidence: rendering and GPU readback are both fine

   Same process, same texture: a manual copy_texture_to_buffer + map_async readback (the approach from examples/app/headless_renderer.rs) returns the correct pixels, while Screenshot::image on that texture returns all zeros:

   manual copy readback: 3686400 bytes, 50% nonzero   (solid-red ClearColor → R+A channels, exactly as expected)
   Screenshot::image:    0% nonzero                   (all black)
   

   No wgpu validation errors at WGPU_LOG=warn. The capture reports success (completion: screenshot_captured, correct dimensions, file written) — it's just full of zeros.

   So this looks like a regression in the Screenshot system's internal blit pipeline (crates/bevy_render/src/view/window/screenshot.rs), not an intentional scoping change — unless dropping support for camera-attached render targets and the primary window is also intended. The blit step in ScreenshotPreparedState (offscreen texture + pipeline) is my prime suspect.

   Minimal reproduction

   use bevy::{
       app::{AppExit, ScheduleRunnerPlugin},
       camera::RenderTarget,
       prelude::*,
       render::{
           render_resource::{TextureFormat, TextureUsages},
           view::screenshot::{save_to_disk, Screenshot, ScreenshotCaptured},
       },
       window::ExitCondition,
       winit::WinitPlugin,
   };
   use std::time::Duration;
   
   fn main() {
       App::new()
           .insert_resource(ClearColor(Color::srgb(1.0, 0.0, 0.0))) // solid red
           .add_plugins(
               DefaultPlugins
                   .set(WindowPlugin {
                       primary_window: None,
                       exit_condition: ExitCondition::DontExit,
                       ..default()
                   })
                   .disable::<WinitPlugin>(),
           )
           .add_plugins(ScheduleRunnerPlugin::run_loop(Duration::from_secs_f64(1.0 / 60.0)))
           .add_systems(Startup, setup)
           .add_systems(Update, capture_at_frame_30)
           .run();
   }
   
   #[derive(Resource, Clone)]
   struct Target(Handle<Image>);
   
   fn setup(mut commands: Commands, mut images: ResMut<Assets<Image>>) {
       let mut img = Image::new_target_texture(1280, 720, TextureFormat::Rgba8UnormSrgb, None);
       img.texture_descriptor.usage |= TextureUsages::COPY_SRC;
       let handle = images.add(img);
       commands.spawn((Camera2d, RenderTarget::Image(handle.clone().into())));
       commands.insert_resource(Target(handle));
   }
   
   fn capture_at_frame_30(mut commands: Commands, target: Option<Res<Target>>, mut frame: Local<u32>) {
       *frame += 1;
       if *frame != 30 { return; }
       let Some(target) = target else { return };
       commands
           .spawn(Screenshot::image(target.0.clone()))
           .observe(save_to_disk("shot.png"))
           .observe(|_: On<ScreenshotCaptured>, mut exit: MessageWriter<AppExit>| {
               exit.write(AppExit::Success);
           });
   }

   Expected: shot.png is solid red. Actual: every pixel byte is 0. The manual-readback counterpart harness (extracts the same GpuImage in the Render schedule and copies it to a MAP_READ buffer) prints the correct data — happy to share it if useful.

   Related: PR #25229 attempted a fix for the no-camera case, but its author closed it unmerged before GPU verification — so no fix has landed in any release, and the broader camera-attached / primary-window cases reported above remain unaddressed.

   One more note: bevy main moved to wgpu 30 in July (#24841), so if this involves a wgpu 29 interaction it may already behave differently on main — I haven't tested main.