Horizontal/Vertical lines interpolation

[DaMilyutin]

Hi, I was rendering bunch of horizontal/vertical lines with plotters in sixtyfps via ImageBuffer.
And I was surprised by effect of variaton of brightness.

To find where it started, I've recreated example output to file (.png)
and got this (as seen thru Win 10 Photos)

NOTE: file size may fiffer from buffer size in first examle.

So I decided to load this file in sixty via @image-url and got this

So is seems like it is not plotters pecularity but the way image is interpolated.
This douesnot bother me a lot but is surprising. So FYI.

X( I think you can recreate this by using my example imagees from Win 10 Photos and using @image-url. )X - upd: no you can't

And I add some code. I removed axes but still get

fn render_plot(width: f32, height: f32) -> sixtyfps::Image {
    let width = width as usize;
    let height = height as usize;
    let mut pixel_buffer = SharedPixelBuffer::new(width, height);
    let size = (pixel_buffer.width() as u32, pixel_buffer.height() as u32);

    let backend = BitMapBackend::with_buffer(pixel_buffer.make_mut_bytes(), size);

    // Plotters requires TrueType fonts from the file system to draw axis text - we skip that for
    // WASM for now.
    #[cfg(target_arch = "wasm32")]
    let backend = wasm_backend::BackendWithoutText { backend };

    let root = backend.into_drawing_area();

    root.fill(&BLACK).unwrap();

    let mut chart = ChartBuilder::on(&root)
        .x_label_area_size(width as f64)
        .y_label_area_size(height as f64)
        .top_x_label_area_size(width as f64)
        .right_y_label_area_size(height as f64)
        .build_cartesian_2d(0f32..width as f32, 0f32..height as f32)
        .unwrap();

    chart
        .configure_mesh()
        .disable_x_mesh()
        .disable_y_mesh()
        .draw()
        .unwrap();

    // horizontal
    // for y in (0..(height / 2)).map(|i| 2.0 * i as f32) {
    //     chart
    //         .draw_series(LineSeries::new(
    //             (0..=1).map(|i| (10. + (i as f32) * (width as f32 - 20.), y)),
    //             ShapeStyle {
    //                 color: WHITE.to_rgba(),
    //                 filled: false,
    //                 stroke_width: 1,
    //             },
    //         ))
    //         .unwrap();
    // }

    // vertical
    for x in (0..(width / 4)).map(|i| 4.0 * i as f32) {
        chart
            .draw_series(LineSeries::new(
                (0..=1).map(|i| (x, 10. + (i as f32) * (height as f32 - 20.))),
                ShapeStyle {
                    color: WHITE.to_rgba(),
                    filled: false,
                    stroke_width: 1,
                },
            ))
            .unwrap();
    }

    root.present().unwrap();

    drop(chart);
    drop(root);
    sixtyfps::Image::from_rgb8(pixel_buffer)
}

In .60

        VerticalBox {
            width: root.width - MenuView.width;
            height: root.height;
            Image {
                //source: @image-url("D:/tmp/test-V.png");
                source: root.render_plot(parent.width, parent.height);
            }
        }

[DaMilyutin]

And It definitely has same rendering issue in browser.
I can not prove my point with screenshots...

[DaMilyutin]

uploaded images from PC. not screenshots.

[ogoffart]

Looks like a Moiré pattern that could be caused by some scaling somewhere in the pipeline. If the image is not rendered at the exact same size of the source, it is going to be scaled. Another problem would occur if we don't draw the image aligned on the pixel grid, which might also be the case.
I'm also seeing some optical illusions looking at the original images, but i guess you don't mean that problem.

[DaMilyutin]

@tronical, If I got you right, I have no idea how to switch to Qt backend with sixtyfps.

...else (if I got you not right):
I haven't tried rendering this image in Qt. (I haven't opened Qt-related projects for a year at least.)

[ogoffart]

To switch backend at runtime, you can use SIXTYFPS_BACKEND=Qt or SIXTYFPS_BACKEND=GL env variables
Note that the Qt backend is normaly the default if Qt is installed.

Anyway, we currently do not make any effort to draw the images aligned on the pixel grid, with any backend. As far as i'm aware. So bluriness could porentially be reproduced with any backend. We do need to fix that.
But that doesn't explain the broken lines though.

[DaMilyutin]

@ogoffart, Installed Qt just now. Will try.
Where do I write env variables? I never did that.

[ogoffart]

In your shell.
assuming you are using windows, it is something like
set SIXTYFPS_BACKEND=Qt
(i think)
But since Qt is the default backend anyway (if it is installed) you don't need to do that

[DaMilyutin]

@ogoffart , tried it. See no difference. Pattern is broken.
I'll retry it in my newer C++ playground when install plotting library there.
However, I think vertical lines are good test case.
Would you create ticket (to be postponed for later but must be tracked) or wait for my newer example?
I plan to do both horizontal and vertical lines subplots and maybe grid.