winit
winit copied to clipboard
Scale factor > 1 causes window to infintely resize untill crash
Description
My code continuously gets code to resize the window to double its existing size. This continues until the window is too large and my program crashes.
Here is the back trace from the console:
__wbg_get_imports/imports.wbg.__wbg_new_8a6f238a6ece86ea@http://127.0.0.1:1334/api/wasm.js:1655:13
input-a6b4e9fb3406cc33.wasm.__wbg_new_8a6f238a6ece86ea externref shim@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[59181]:0x133cdb1
input-a6b4e9fb3406cc33.wasm.console_error_panic_hook::Error::new::h1ab588f5577ee9b5@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[37913]:0x11fd6e7
input-a6b4e9fb3406cc33.wasm.console_error_panic_hook::hook_impl::h9b3357f458337699@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[10197]:0xcf3ddf
input-a6b4e9fb3406cc33.wasm.console_error_panic_hook::hook::h514c9ff8c9427eff@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[51393]:0x12e68e4
input-a6b4e9fb3406cc33.wasm.core::ops::function::Fn::call::h090f29b54bcca2bd@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[45441]:0x128e655
input-a6b4e9fb3406cc33.wasm.std::panicking::rust_panic_with_hook::heb1fa7c95b92daf7@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[21933]:0xffe617
input-a6b4e9fb3406cc33.wasm.std::panicking::begin_panic_handler::{{closure}}::h3c2bc8468c50b1ce@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[25711]:0x109e597
input-a6b4e9fb3406cc33.wasm.std::sys::backtrace::__rust_end_short_backtrace::h8e8868764214f28d@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[60419]:0x1340cfd
input-a6b4e9fb3406cc33.wasm.rust_begin_unwind@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[56657]:0x1328c01
input-a6b4e9fb3406cc33.wasm.core::panicking::panic_fmt::h067fb97c138f603d@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[56658]:0x1328c2e
input-a6b4e9fb3406cc33.wasm.wgpu::backend::wgpu_core::default_error_handler::h841a19a78f04fcb1@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[10616]:0xd1c52c
input-a6b4e9fb3406cc33.wasm.wgpu::backend::wgpu_core::ErrorSinkRaw::handle_error::h1d1fd61f5c608951@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[2700]:0x83ce9b
input-a6b4e9fb3406cc33.wasm.wgpu::backend::wgpu_core::ContextWgpuCore::handle_error_inner::h7293525610429fd4@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[2885]:0x876531
input-a6b4e9fb3406cc33.wasm.wgpu::backend::wgpu_core::ContextWgpuCore::handle_error_nolabel::h5eee4168f6950a41@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[16634]:0xedfc4c
input-a6b4e9fb3406cc33.wasm.<wgpu::backend::wgpu_core::CoreSurface as wgpu::dispatch::SurfaceInterface>::configure::h07e2ab357b04ce32@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[3785]:0x95a2e8
input-a6b4e9fb3406cc33.wasm.wgpu::api::surface::Surface::configure::hbaa03d6748007c27@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[4927]:0xa3fa2e
input-a6b4e9fb3406cc33.wasm.bottomless_pit::engine_handle::Engine::resize::h5603d1aabc514868@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[4783]:0xa2594d
input-a6b4e9fb3406cc33.wasm.<(T,bottomless_pit::engine_handle::Engine) as winit::application::ApplicationHandler<bottomless_pit::engine_handle::BpEvent>>::window_event::hd37b561234ca5a95@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[1841]:0x6ddd92
input-a6b4e9fb3406cc33.wasm.<winit::event_loop::EventLoop<T> as winit::platform::web::EventLoopExtWebSys>::spawn_app::{{closure}}::h63e8ca67d30795bc@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[3564]:0x926de1
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::EventLoop<T>::spawn::{{closure}}::hc552365bb1c4f473@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[6378]:0xb2e057
input-a6b4e9fb3406cc33.wasm.<alloc::boxed::Box<F,A> as core::ops::function::FnMut<Args>>::call_mut::hd9d77753ab5357dd@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[29937]:0x112c9e4
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::runner::Runner::handle_single_event::h10e1253ef7500c61@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[4334]:0x9cf7c6
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::runner::Shared::handle_event::ha4b400517e723341@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[1666]:0x678152
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::runner::Shared::run_until_cleared::hf6bd99851507c703@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[3454]:0x90ce80
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::runner::Shared::send_events::h0859316567e306dd@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[1832]:0x6d9388
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::runner::Shared::send_event::hb2bf113846ce4bc2@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[36147]:0x11d5a13
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::event_loop::window_target::ActiveEventLoop::register::{{closure}}::hd778acf67cd19718@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[6569]:0xb49e87
input-a6b4e9fb3406cc33.wasm.<alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h11e8a6b34141cfaf@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[34102]:0x11a2c59
input-a6b4e9fb3406cc33.wasm.winit::platform_impl::web::web_sys::resize_scaling::ResizeScaleInternal::new::{{closure}}::{{closure}}::h1e01e5e7ff147e65@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[3289]:0x8e462d
input-a6b4e9fb3406cc33.wasm.<dyn core::ops::function::FnMut<(A,B)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hefb57604e8dacbf6@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[20113]:0xfa3cb4
input-a6b4e9fb3406cc33.wasm.closure735 externref shim@http://127.0.0.1:1334/api/wasm.wasm:wasm-function[58587]:0x1339203
__wbg_adapter_49@http://127.0.0.1:1334/api/wasm.js:263:6
real@http://127.0.0.1:1334/api/wasm.js:163:32
and here is a log of every event that occurs:
INFO app: WaitCancelled { start: Instant(396.54ms), requested_resume: None }
INFO app: event: RedrawRequested, WindowId(1)
INFO app: WaitCancelled { start: Instant(412.48ms), requested_resume: None }
INFO app: event: Resized(PhysicalSize { width: 1200, height: 1200 }), WindowId(1)
INFO app: WaitCancelled { start: Instant(414.64ms), requested_resume: None }
INFO app: event: RedrawRequested, WindowId(1)
INFO app: WaitCancelled { start: Instant(435.6ms), requested_resume: None }
INFO app: event: Resized(PhysicalSize { width: 2400, height: 2400 }), WindowId(1)
INFO app: WaitCancelled { start: Instant(436.58ms), requested_resume: None }
INFO app: event: RedrawRequested, WindowId(1)
INFO app: WaitCancelled { start: Instant(456.3ms), requested_resume: None }
INFO app: event: Resized(PhysicalSize { width: 4800, height: 4800 }), WindowId(1)
INFO app: WaitCancelled { start: Instant(457.72ms), requested_resume: None }
INFO app: event: RedrawRequested, WindowId(1)
INFO app: WaitCancelled { start: Instant(556.5ms), requested_resume: None }
INFO app: event: Resized(PhysicalSize { width: 9600, height: 9600 }), WindowId(1)
INFO app: WaitCancelled { start: Instant(557.9ms), requested_resume: None }
INFO app: event: RedrawRequested, WindowId(1)
INFO app: WaitCancelled { start: Instant(1.04202s), requested_resume: None }
INFO app: event: Resized(PhysicalSize { width: 19200, height: 19200 }), WindowId(1)
Tested browsers
Firefox
Tested devices
I'm on a Arch laptop running Firefox
Winit version
0.30.8
I've found that this doesn't happen if I disable drawing with softbuffer, so it may be an unfortunate interaction between Winit and that?
I am not using softbuffer to draw at least to my knowledge as I use wgpu to render to the window.
I'm observing this bug too. It happens in Firefox on my M1 MacBook Pro, but doesn't happen in Firefox on my Linux machine. When I run the same application natively on my Mac, the scale factor is 2, while it is 1 on my Linux machine. So, given this, I suspect the doubling might have something to do with the difference in scale factor between the two platforms.
Interesting I thought that as well and can confirm on my computer the scale factor is 2, however not sure why this is occuring when I do not call resize at any point or make an attempt to put the scale factor into account. Is there a way to force a scale factor of 1?
Just tested on a different computer that had a scale factor of 1.2 lo and behold the window grew by 1.2 times untill crashing.
@madsmtm I can reproduce this issue in my winit+wgpu integration project. Here are my findings:
Environment Details
- Device pixel ratio: 2.0
- Reproduction scenario: Occurs when creating window with detached canvas (not in DOM)
Reproduction Steps
- Create window using either approach:
- No canvas specified in
WindowAttributes - Canvas element exists but is not appended to document (detached state)
- No canvas specified in
- Append canvas to body after window creation
Observed Behavior with Detached Canvas
Initial canvas state:
<canvas width="100" height="100"></canvas>
Event sequence:
Window creation triggers resize(100, 100) Surface resized to (100, 100) Automatic resize(200, 200) triggered Enters resize feedback loop
Working Scenarios
The issue is avoided when:
-
Pre-attached canvas (appended to DOM before window creation):
<canvas width="100" height="100" style="width:200px; height:200px"></canvas> -
Style pre-initialized:
<canvas width="100" height="100" style="width:200px; height:200px"></canvas>
@EggShark @jdisanti you can try my Temporary solution implementation reference1
This works!! Ty so much I've been working at this for almost a year now. For refrence this was my window/canvas creation code prior which caused the scaling:
#[cfg(target_arch = "wasm32")]
{
use crate::engine_handle::BuildError;
use winit::platform::web::WindowExtWebSys;
let web_window = web_sys::window()
.ok_or(BuildError::CantGetWebWindow)
.unwrap();
let canvas = web_sys::Element::from(window.canvas().unwrap());
let document = web_window
.document()
.ok_or(BuildError::CantGetDocument)
.unwrap();
match document.get_element_by_id(&title) {
Some(element) => {
let array = js_sys::Array::new();
array.push(&wasm_bindgen::JsValue::from(canvas));
element.replace_with_with_node(&array).unwrap();
}
None => {
log::warn!(
"coudn't find desitantion <canvas> with id: {}, appending to body",
&title
);
canvas.set_id(&title);
let body = document.body().ok_or(BuildError::CantGetBody).unwrap();
body.append_child(&canvas).unwrap();
}
}
}
This is it now with it functioning:
#[cfg(target_arch="wasm32")]
{
use crate::engine_handle::BuildError;
use winit::platform::web::WindowAttributesExtWebSys;
use wasm_bindgen::JsCast;
let document = web_sys::window()
.ok_or(BuildError::CantGetWebWindow)
.unwrap()
.document()
.ok_or(BuildError::CantGetDocument)
.unwrap();
let canvas = document.create_element("canvas")
.unwrap()
.dyn_into::<web_sys::HtmlCanvasElement>()
.unwrap();
let style = canvas.style();
let _ = style.set_property("width", "100%");
let _ = style.set_property("height", "100%");
match document.get_element_by_id(&title) {
Some(element) => {
let array = js_sys::Array::new();
array.push(&wasm_bindgen::JsValue::from(&canvas));
element.replace_with_with_node(&array).unwrap();
}
None => {
log::warn!(
"coudn't find desitantion <canvas> with id: {}, appending to body",
&title
);
canvas.set_id(&title);
let body = document.body().ok_or(BuildError::CantGetBody).unwrap();
body.append_child(&canvas).unwrap();
}
}
window_options.attributes = window_options.attributes.with_canvas(Some(canvas));
}
let window = Arc::new(event_loop.create_window(window_options.attributes).unwrap());
Not sure if this issue should be closed now or left open so the other code can be fixed
I'm also experiencing this issue. In addition, scale factors less than 1 cause the canvas to repeatedly resize to get smaller (until reaching a minimum size).
I was able to work around this by constraining the window size:
window.set_min_inner_size(Some(PhysicalSize::new(1280, 720)));
window.set_max_inner_size(Some(PhysicalSize::new(1280, 720)));