Size bug with window.set_decorations(false)

[Bowarc]

Describe the bug
When using window.set_decorations(false) with a fixed size, the window is slightly too big, so it has black borders

To Reproduce
Set up a window with fixed size then set window.set_decorations(false)

Expected behavior
To have a frameless window of the size i gave it

Screenshot

The code in question

use image::{DynamicImage, ImageBuffer, Rgba};
use pixels::{Pixels, SurfaceTexture};
use winit::{
    dpi,
    event::{DeviceEvent, ElementState, Event, MouseButton, VirtualKeyCode, WindowEvent},
    event_loop::{ControlFlow, EventLoop},
    window::WindowBuilder,
};

fn main() {
    let im: DynamicImage = image::open("Thresh_6.png").unwrap();
    let rgba: ImageBuffer<Rgba<u8>, Vec<u8>> = im.to_rgba8();

    let width = rgba.width();
    let height = rgba.height();

    println!("{} x {}", width, height);
    // Prints 1215 x 717 (the correct image size)

    let event_loop = EventLoop::new();

    let window = WindowBuilder::new()
        .with_inner_size(dpi::LogicalSize::new(width, height))
        .build(&event_loop)
        .unwrap();

    window.set_decorations(false);

    let window_size = window.inner_size();

    println!("{} x {}", window_size.width, window_size.height);
    // Prints 1231 x 756 for some reason

    let surface_texture = SurfaceTexture::new(window_size.width, window_size.height, &window);

    let mut pixels = Pixels::new(width, height, surface_texture).unwrap();

    let data = rgba.into_vec();
    let frame = pixels.get_frame();

    for (index, i) in data.iter().enumerate() {
        frame[index] = *i;
    }

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Poll;

        *control_flow = ControlFlow::Wait;

        match event {
            Event::WindowEvent { event, .. } => match event {
                WindowEvent::CloseRequested => {
                    println!("The close button was pressed; stopping");
                    *control_flow = ControlFlow::Exit
                }
                WindowEvent::MouseInput { state, button, .. } => match button {
                    MouseButton::Left => match state {
                        ElementState::Pressed => {
                            window.drag_window().unwrap();
                        }
                        _ => {}
                    },
                    _ => {}
                },
                _ => {}
            },
            Event::MainEventsCleared => {
                window.request_redraw();
            }
            Event::RedrawRequested(_) => {
                let _render_result = pixels.render_with(|encoder, render_target, context| {
                    context.scaling_renderer.render(encoder, render_target);
                    Ok(())
                });
            }
            Event::DeviceEvent {
                device_id: _,
                event: DeviceEvent::Key(keyboard_input),
            } => match keyboard_input.virtual_keycode {
                Some(code) => match code {
                    VirtualKeyCode::Escape => *control_flow = ControlFlow::Exit,
                    _ => {}
                },
                None => {}
            },
            _ => (),
        }
    });
}

The image used in the code: Thresh_6.png

[maroider]

The issue, at its core, appears to be that the window size we tell Windows we want, isn't the one we get, even in the absence of pixels (which shouldn't have an effect on this in the first place).

Something strange is going on with WM_NCCALCSIZE, and I tried setting the first to rects in NCCALCSIZE_PARAMS to the third rect in said struct, and that let me get the correct size for the client area, but the window decorations (or rather, the area they would otherwise occupy) were still "there", but broken. I'll have to check my local changes to #1891 and see if there's something there that can help us.

A question that remains is whether #1933 had anything to do with this issue, and knowing my luck, it just might. If 0.24.0 doesn't have the bug, then #1933 may be at fault in some way. I did not test this with 0.25.0.

This might also be related to #2094.