Surface::get_current_texture does not block when the window is fully invisible (macOS) #4779
Comments
|
Setting to fullscreen with The issue does not present when using Vulkan with MoltenVK. |
|
Try again now that #4781 has landed |
|
This doesn't reproduce for me basically identical setup on trunk. Going to close, if you tell me it's still happeneing I'll reopen. |
|
This still happens to me after updating wgpu ( Sometimes resizing to fullscreen only will not trigger the issue. However, the issue will present swapping to other desktop using trackpad and then swapping back to the fullscreen app. I have updated my git repo of the demo. |
With further investigation using Instrument I found that The stack trace in a single call: |
|
With further investigation I located the issue to the execution time of In the event loop, I use the following structure to render: match event {
Event::WindowEvent { event, .. } => match event {
WindowEvent::RedrawRequested => {
match state.render() {
Ok(_) => {}
Err(wgpu::SurfaceError::Lost) => {
warn!("Lost surface");
state.resize(state.size)
}
Err(wgpu::SurfaceError::OutOfMemory) => panic!("Out of memory"),
Err(e) => eprintln!("{:?}", e),
}
println!(
"Rendered in {}ms",
render_start.elapsed().as_micros() as f32 / 1000.0
);
}
_ => {}
},
Event::AboutToWait => {
state.window().request_redraw();
}
_ => {}
}Generally, However, when putting the window into another desktop, or setting fullscreen mode then switch to other desktops, the window becomes fully invisible. This cause the time of calling Since the render has finished, |
ComfyFluffy
changed the title
|
For those wondering how to mitigate this issue if affected by it while a proper fix lands, this comment I made for the previous big memory leak may help: sotrh/learn-wgpu#207 (comment). The key thing of these two mitigations is avoiding drawing or limiting the number of frames drawn when the window is occluded, which helped with the previous issue; in this case, it might help in this case if you can detect whether the window is unfocused (thus, in particular, the CVDisplayLink hack I made may fix the issue entirely). Bevy mitigated this, for example, by limiting the rate of frames rendered when the app was in the background, see bevyengine/bevy#7611. |
Description
I am currently following a WGPU Tutorial and have implemented Hello Triangle with vertex buffers.
When I click the green button to expand the window into fullscreen, the process will suddenly take up to 22GB of memory:
After a few seconds, the memory usage goes down:
Repro steps
I have uploaded the code onto GitHub.
git clone https://github.com/ComfyFluffy/wgpu-tutorial.git cd wgpu-tutorial RUST_LOG=info MTL_HUD_ENABLED=1 cargo runThen expand the app to fullscreen.
If expanding to fullscreen does not cause memory peak, switching to other desktop then switch back to the app can also cause it.
Resizing on windowed mode does not trigger the behavior.
Resizing on Windows 11 does not trigger the behavior.
Expected vs observed behavior
Expected: The memory usage should remain largely the same during resizing.
Observed: The memory usage goes up to 22 GB.
Extra materials
Info log logged by
env_logger. Memory peak happened during resizing.Platform
Macbook Pro 14 (2021), M1 Pro with macOS Sonoma, 16 GB Memory
wgpu: 0.18.0The text was updated successfully, but these errors were encountered: