Visual tearing with `ImageFilterMode::Nearest`

[musjj]

Bevy version

0.15.0

What you did

When ImageFilterMode::Nearest is set as the default sampler, tearing occurs to text, sprites, etc. when the window resolution is an odd number (101x303, etc.). You can test by spawning a sprite and then resizing the window:

use bevy::prelude::*;

fn main() -> AppExit {
    App::new()
        .add_plugins(DefaultPlugins.set(ImagePlugin::default_nearest()))
        .add_systems(Startup, setup)
        .run()
}

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

    commands.spawn(Sprite::from_image(asset_server.load("grid_480x270.png")));
}

The notable exception is that it doesn't happen to sprites with dimensions that is the power of two (512x256, etc.).

You can test a more elaborate, interactive reproduction here: https://github.com/musjj/nearest_filter_bug. Slowly and gradually resize the window and you should be able to see the artifacts popping in and out.

What went wrong

Visual tearing occurs.

Additional information

An example of no tearing:

An example of tearing:

A closeup of the tearing (the lines are supposed to be perfectly straight):

[sophrosyne97]

I did happen to notice this back right before 0.15.0 was released, specifically in 0.15.0-rc3 when running the pixel_grid_snap.rs example. When I did a git bisect to see which commit it started it on, it ended up on this particular one: #15969.

It still happens to me on release-0.15.0 as well, although strangely I can only reproduce it on Linux; on Windows I can't seem to ever produce the effect (although resizing the window doesn't update quite the same where I can see it resize to each pixel as I drag, I'd have to drag and let go to see it which means I might be missing it at some particular window size)

As for the System and Adapter info:
SystemInfo { os: "Linux rolling Arch Linux", kernel: "6.12.3-arch1-1", cpu: "AMD Ryzen 9 5900X 12-Core Processor", core_count: "12", memory: "31.3 GiB" }
AdapterInfo { name: "AMD Radeon RX 6900 XT (RADV NAVI21)", vendor: 4098, device: 29615, device_type: DiscreteGpu, driver: "radv", driver_info: "Mesa 24.3.1-arch1.2", backend: Vulkan }

You can see the tearing near the bottom left of the mesh in the pixel_grid_snap.rs example

[musjj]

@sophrosyne97

THANK YOU for the bisect, that was it! It looks like that it's a rounding bug, applying this patch fixes the issue:

diff --git a/crates/bevy_render/src/camera/projection.rs b/crates/bevy_render/src/camera/projection.rs
index 7deb061..05271c1 100644
--- a/crates/bevy_render/src/camera/projection.rs
+++ b/crates/bevy_render/src/camera/projection.rs
@@ -494,10 +494,10 @@ impl CameraProjection for OrthographicProjection {
         let origin_y = projection_height * self.viewport_origin.y;
 
         self.area = Rect::new(
-            self.scale * -origin_x,
-            self.scale * -origin_y,
-            self.scale * (projection_width - origin_x),
-            self.scale * (projection_height - origin_y),
+            (self.scale * -origin_x).round(),
+            (self.scale * -origin_y).round(),
+            (self.scale * (projection_width - origin_x)).round(),
+            (self.scale * (projection_height - origin_y)).round(),
         );
     }

But I'm not sure how "correct" this patch is. If you want to open a PR, go ahead!

[sophrosyne97]

@musjj

No problem! That patch does solve the tearing issue for me, but I still unfortunately seem to get some form of pixel distortion when I resize the window. Specifically, as I resize the window I can see some of the pixels changing in size such that one pixel can appear more "smushed" than another, and all the pixels of a sprite seem to be kind of shifting around in size which I didn't experience in 0.14.2. Unfortunately I have to leave for work soon, but when I come back I'll try to take some webms to make things more clear and try to tinker with it.

[musjj]

You're right, I'm noticing that too. I tried to reproduce it in 0.14 and it works perfectly there like you said. No tearing, no pixel shifting. You can try out my repro here: https://github.com/musjj/nearest_filter_regression. There's a 0.14 and 0.15 branch.

I first thought that the pixel shifting is necessary because the sprite and window pixels aren't aligned. But I guess there's a better way to deal with this as shown in 0.14.

[musjj]

Ok I think I got it, it's way simpler than I thought:

diff --git a/crates/bevy_render/src/camera/projection.rs b/crates/bevy_render/src/camera/projection.rs
index 7deb061..c39fcf5 100644
--- a/crates/bevy_render/src/camera/projection.rs
+++ b/crates/bevy_render/src/camera/projection.rs
@@ -490,8 +490,8 @@ impl CameraProjection for OrthographicProjection {
             ScalingMode::Fixed { width, height } => (width, height),
         };
 
-        let origin_x = projection_width * self.viewport_origin.x;
-        let origin_y = projection_height * self.viewport_origin.y;
+        let origin_x = (projection_width * self.viewport_origin.x).round();
+        let origin_y = (projection_height * self.viewport_origin.y).round();
 
         self.area = Rect::new(
             self.scale * -origin_x,

No tearing or shifting this time 😄

Hopefully, this won't cause any regressions somewhere else.

[sophrosyne97]

Yep, works for me as well!

Much appreciated, this issue was bothering me quite a bit 🥲

Nice job!