AppKit: Expose native transition state - #4610
Conversation
67ace9c to
086c209
Compare
086c209 to
d7af73e
Compare
|
Hm, I think AppKit has a separate event end point which it calls during live resize. I think other platforms have the same concept of interactive resize, but they tend to deliver event via usual resize mechanism. I'm just not quite sure why this extra information is only needed on macOS and not on e.g. Wayland for wgpu to work. I do remember this stretching of viewport type of issue though myself in alacritty, and we never bothered to deal with it on macOS. That being said, can we somehow handle it via regular Resize event? Or maybe exposing some state information along resize to indicate that it's interactive resize or something to solve this problem on macOS, so it'll be done in a cross platform way and users won't have to worry about such thing? |
Summary
This exposes AppKit native transition state through
WindowExtMacOS:WindowExtMacOS::is_live_resizing()for AppKit live-resize transitions.WindowExtMacOS::is_fullscreen_transition()for native fullscreen enter/exit transitions.It also keeps macOS maximized state cached so callers can poll
Window::is_maximized()without forcingNSWindow.isZoomedto temporarily mutate window style masks, and requests a final redraw when AppKit completes native fullscreen transitions.Motivation
Renderer integrations need to know when AppKit is driving native window transitions so they can synchronize surface presentation and avoid stale or stretched frames during live resize and fullscreen animations.
For a specific example see this egui PR emilk/egui#8280 that depends on this winit PR.
Checks
cargo +nightly fmt --checkcargo check -p winit --all-features