Fix AppKit live resize redraw timing

[yay]

This fixes macOS live-resize behavior for layer-backed winit views.

While investigating resize artifacts in a downstream app and looking at other AppKit/Metal applications with smooth live resize behavior such as Zed editor, I found that AppKit can update and ask a layer-backed content view to display during live resize through paths that winit was not fully using for surface resize/redraw timing.

The main issue is that during live resize, the view backing size and redraw timing need to stay synchronized with AppKit's resize/display callbacks. Otherwise surface users can render with stale size information or miss redraw opportunities during the event-tracking run loop. In practice this shows up as visible wobble/jitter and stale or stretched frames while the window edge or corner is being dragged.

This PR changes the AppKit view path to:

• set NSViewLayerContentsRedrawDuringViewResize for the content view
• handle setFrameSize: by updating the surface size and requesting redraw during live resize
• handle viewDidChangeBackingProperties for backing-scale/backing-size changes
• handle displayLayer: as a redraw signal during live resize
• report surface size from convertRectToBacking(bounds) instead of deriving it from the window/frame size

Validation

I used a small winit + CAMetalLayer demo that:

• renders an animated high-contrast grid
• paints only from WindowEvent::RedrawRequested
• does not use an external AppKit timer
• does not enable CAMetalLayer.presentsWithTransaction

I recorded the same demo before and after the fix:

Before:

before-the-fix.mp4

After:

after-the-fix.mp4

In the before video, live resize shows stale/stretched frames. In the after video, resizing stays synchronized and smooth.

I also validated the same change against winit 0.30.13, since that is the version used by the downstream app where I first reproduced the issue.

---

Downstream validation/follow-up in egui: emilk/egui#8229.

That PR uses this winit change as the windowing-layer part of the fix, then handles the renderer-specific egui-wgpu/Metal presentation policy separately.

[yay]

@madsmtm Gentle bump - does this approach look acceptable?

[kchibisov]

@tronical @ogoffart would you mind taking a look? I don't have macOS machine around to check macOS stuff myself, but this might be interesting to you?

[tronical]

Wouldn't it be possible here to use https://docs.rs/objc2-app-kit/latest/objc2_app_kit/struct.NSView.html#method.setLayerContentsRedrawPolicy ?

[tronical]

I'm curious as to why this is needed, when setPostsFrameChangedNotifications(true) is active on the view.

[tronical]

Is there a risk that drawRect isn't called anymore when displayLayer? I have this vague memory, but perhaps this applies only to UIKit.

[tronical]

I think you can do this even without unsafe:

Suggested change

	unsafe {
	// 2 == NSViewLayerContentsRedrawDuringViewResize. Ask AppKit to redisplay the
	// layer while the view is being resized so layer-backed surfaces keep painting.
	let _: () = msg_send![&*this, setLayerContentsRedrawPolicy: 2isize];
	}
	this.setLayerContentsRedrawPolicy(NSViewLayerContentsRedrawPolicy::DuringViewResize);

[tronical]

Looks overall good to me. A few questions inside, and I think that unsafe call can be replaced with a clean safe call :)