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

Winit example crashes on wayland with dpi scaling #523

Open
TXPGhost opened this issue Dec 27, 2024 · 1 comment
Open

Winit example crashes on wayland with dpi scaling #523

TXPGhost opened this issue Dec 27, 2024 · 1 comment

Comments

@TXPGhost
Copy link

The winit example crashes on my system (running GNOME under Wayland) with the following error:

wl_surface#25: error 2: Buffer size (1748x45) must be an integer multiple of the buffer_scale (2).

It seems to have something to do with the window decoration, since adding .with_decorations(false) to the window builder seems to be a workaround (or alternatively, by adding borderless: true to the WindowSettings when creating a three_d::Window). The size (1748x45) seems to suggest the issue lies with the window decorations.

The issue is also fixed by using 100% UI scaling rather than 200% (changed in the GNOME settings menu).

The crash seems to occur on line main.rs:73 of the winit_window example while the buffers are swapped.

context.swap_buffers().unwrap();

I also tested the eframe and pixels crates under the same conditions, and they were able to run fine, suggesting the issue is not upstream. Any ideas what may be causing this?

@asny
Copy link
Owner

asny commented Jan 2, 2025

Hmm. I think the error message is pretty clear, the window surface size needs to be a multiple of 2. 45 is not a multiple of 2. So just ensure that the window size is a multiple of 2 and your good. Alternatively, you can handle the error in the line context.swap_buffers().unwrap(); instead of unwrapping. Or any of the other workarounds you suggested.

Anyway, since three-d is using winit and winit returns an error in this case which is also returned by three-d, and which you can just handle yourself, I don't really see what needs to be changed?

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

No branches or pull requests

2 participants