Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendered window content size is out of sync and padded #314

Closed
Abdillah opened this issue Oct 27, 2022 · 4 comments
Closed

Rendered window content size is out of sync and padded #314

Abdillah opened this issue Oct 27, 2022 · 4 comments
Labels
question Usability question

Comments

@Abdillah
Copy link

I run the raquote-winit example in GNOME with Wayland and get the following result.

image

It is padded and the size is out of sync. This is the case in animated render.

For static render, at the first render (before the cursor enter or interact), the size is fine. But soon as I touch the window, it goes out of sync and padded as in the picture.

The padded is actually passing through, as my cursor become and edit handle on top of a terminal.

@parasyte parasyte added the question Usability question label Oct 28, 2022
@parasyte
Copy link
Owner

parasyte commented Oct 28, 2022

Hi!

The border is expected when scaling to non-integer multiples.

When you say "the size is fine" on what I presume is the first frame shown... I assume you say this because it doesn't have a border in this case. That would actually be a bug. The image should always have a border when the window surface size is not an exact integer multiple of the pixel buffer size.

Measuring the frame size in your screenshot, it is exactly 400x400, which is the requested size in the demo:

const WIDTH: u32 = 400;
const HEIGHT: u32 = 400;

Measuring the window's inner size, it is something like 420x445. The border is 100% correct in the screenshot.

Without more information, I can only guess that there are two issues:

  1. The window is not created with an appropriate size. According to the winit docs, setting the window's inner size is supported on Wayland. The size is configured here in the raqote demo:
    let window = {
    let size = LogicalSize::new(WIDTH as f64, HEIGHT as f64);
    WindowBuilder::new()
    .with_title("Hello Raqote")
    .with_inner_size(size)
    .with_min_inner_size(size)
    .build(&event_loop)
    .unwrap()
    };
  2. The surface is resized "late". Maybe the window manager only sends the resize event to the window after the first interaction. The resize event is handled here:
    // Resize the window
    if let Some(size) = input.window_resized() {
    pixels.resize_surface(size.width, size.height);
    }

Both of these are entirely contained in the example code, so the main library crate isn't affected. And because the issue described cannot be reproduced on Windows or macOS, it sounds like this is just another Wayland snowflake behavior as implemented in winit. (There are a lot of Wayland-only issues that we've already addressed, you can see some examples by going through the closed issues.)

This needs some more information and a closer investigation. But at the moment, I think the bug is not quite what is described in the OP.

@Abdillah
Copy link
Author

Thanks! You're right down to the pixel. it is true that the resize event is send upon interaction.

The solution in my code (not the example, though) is to add similar to the raqote-winit, by listening to resize event and then add pixels.resize_buffer as well because it what makes the padding gone completely.

@parasyte
Copy link
Owner

Just keep in mind that the resize_buffer() method changes the physical resolution of the pixel frame buffer instead of just scaling. There is an open PR that attempts to implement non-integer scaling (while maintaining the highest quality sharp pixel definition): #262. The PR has some unresolved issues.

@Abdillah
Copy link
Author

resize_buffer() method changes the physical resolution

Right, on the raqote-winit demo, I tried to resize the buffer but forgot that the DrawingTarget must be resized too. The result was such distortion.

There is an open PR that attempts to implement non-integer scaling

That would be a great feature.

My main concern in the OP has been solved, so closing this..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Usability question
Projects
None yet
Development

No branches or pull requests

2 participants