Pixels towards the border of an image are cut off

[pixelcat64]

Is your issue REALLY a bug?

• [x] My issue is indeed a bug!
• [x] I am not crazy! I will not fill out this form just to ask a question or request a feature. Pinky promise.

Is there an existing issue for this?

• [x] I have searched the existing issues.

Is this issue related to iced?

• [x] My hardware is compatible and my graphics drivers are up-to-date.

What happened?

I'm using a viewer widget for an app I am working on, and i've noticed that towards the borders of the image the pixels appear to be cut off. This happens on both the Viewer widget, and the image widget.

I've written this quick example using the image crate and iced (the master version)

use iced::widget::image::{Handle, Viewer};
use iced::widget::{Column, Container, button, column, text};
use iced::{Center, Length};
use image::{GenericImageView, Pixel, Rgba, RgbaImage};

use rand::prelude::*;

pub fn main() -> iced::Result {
    iced::run("test", Counter::update, Counter::view)
}

#[derive(Default)]
struct Counter {}

#[derive(Debug, Clone, Copy)]
enum Message {}

impl Counter {
    fn update(&mut self, message: Message) {}

    fn view(&self) -> Container<Message> {
        let mut rng = rand::rng();
        let image_handle = Handle::from_rgba(
            14,
            14,
            RgbaImage::from_fn(14, 14, |x, y| {
                Rgba([
                    rng.random_range(0..255),
                    rng.random_range(0..255),
                    rng.random_range(0..255),
                    255,
                ])
            })
            .to_vec(),
        );
        Container::new(
            Viewer::new(image_handle)
                .width(Length::Fill)
                .height(Length::Fill)
                .filter_method(iced::widget::image::FilterMethod::Nearest),
        )
        .align_x(Center)
    }
}

What is the expected behavior?

The pixels towards the border should be completely rendered

Version

master

Operating System

Linux

Do you have any log output?

[Remmirad]

I think this might be caused by this https://github.com/iced-rs/iced/blob/4b075b9731f4658a885357024cc77dee10e223c3/wgpu/src/image/mod.rs#L598 here the image is shrunk by half a pixel. Possibly to avoid drawing bits of other adjacent images?

[DKolter]

Removing the offsets does indeed display the image correctly. The offset was probably added to move the texture coordinates to the middle of the texel, preventing texture bleeding from close images in the atlas. I tried to trigger texture bleeding by putting a small black and white image next to each other in the texture atlas, but there were no artifacts with Nearest or Linear filtering. Is there an example with texture bleeding that lead to the offset being added?

Rather than offsetting the texture coordinate we could also look into texture atlas padding, which I didn't see implemented in the current allocator yet.

Bevy implemented texture atlas padding in this PR: https://github.com/bevyengine/bevy/pull/9494

[peterkrull]

+1 to being affected by this. I am assembling OSM tiles, and I get this unsightly offset where tiles meet, often being most noticeable with text. Simply removing the offset from the wgpu implementation causes colors to bleed when using linear interpolation.