macOS: workaround wobbly MTKView resizing

[Seb-degraff]

Workaround for the MTKView resizing glitch by "anchoring" the layer to the window corner opposite to the currently manipulated corner (or edge). This prevents the content stretching back and forth during resizing. This is basically this: https://github.com/floooh/sokol/issues/700

As pointed out in the glitchess resizing blogpost, layerContentsPlacement = .topLeft helps because it prevents stretching the content of the layer while waiting for the correctly sized frame to be rendered. However it works only if the rendered elements are top left aligned. If there are elements that are rendered in the bottom right of the frame and the user resizes from the top left of the window, these elements will appear to shake as they get moved when resizing, then "aligned back" when the frame is rendered.

My solution is to detect which corner is being resized and set layerContentsPlacement accordingly in windowWillStartLiveResize.

Before:

https://github.com/floooh/sokol/assets/6556843/2172ed47-7ef7-476e-ac92-a5c74077e04d

Notice the blue squares stretching while resizing. Pausing the video near the end makes it even more obvious.

After:

https://github.com/floooh/sokol/assets/6556843/7047c9ba-244d-4421-ac43-7ada9a393b53

Notice the blue squares stability independent of which corner is being dragged. Pausing the video makes the latency apparent in the form of grey padding on the resized sides. Barely noticeable at 120 fps.

This workaround can be removed if/when migrating to CAMetalLayer: https://github.com/floooh/sokol/issues/727

Untested: dragging a window from a high dpi to a non high dpi monitor (I can test this in a few days if needed).

[floooh]

Wow, interesting and unexpectedly simple fix! I'll give it a whirl tomorrow and see how it looks on my side!

[floooh]

Gave it a whirl and it looks great!

I tested on the configs I have here with the samples imgui-sapp and imgui-highdpi-sapp:

• 2021 M1 14"MBP, Sonoma 14.1.2: looking perfect
• 2014 Intel 13"MBP, latest Big Sur: looking perfect
• an external 1080p@60Hz monitor attached to the M1 Mac: moving windows to the external display, resizing has different types of artefacts but all in all a slight improvement than before (for some reason, everything has always been slower on this external monitor connected to my M1 Mac, so we shouldn't pay too much attention to this config, on my old Mac with 60Hz integrated display it looks as good as one can expect)

...going to merge now...

[floooh]

...and merged. Many thanks for picking up the issue and creating this perfect little PR :)

...will also add a changelog update now.

[Seb-degraff]

Thank you for testing and merging so fast! And for the kind words!

By the way I really appreciate your work on the sokol libs, it's not an understatement to say they changed my programmer life! So I'm glad to be able to contribute back :)

For good measure I also tested this setup:

• 2023 M2 Pro 16'' with an external 4K monitor manually set to 1080p@60Hz (so not retina). Resizing works as expected. One minor thing I noticed is that when dragging the window from the high-dpi screen to the 1080p screen, there are two frames after the transition that are wrong, 2x too big. I guess that's because the scaleFactor is adjusted right away, but there is already frames in flight with the old frame buffer resolution? I think this such a rare situation that we don't need to bother fixing it though... Here is a screen capture of the artefact:

https://github.com/floooh/sokol/assets/6556843/1b1f574a-6f2a-459a-95d9-01f28409c846