Improve metal frame rendering when more than one display is connected #5847
Conversation
There was a problem hiding this comment.
Looks solid. Timing of calling the function is no longer needed now with ppy/veldrid@7beb127, since if the game is running on multithreaded and the function happened to be called while the draw thread is in the middle of a frame, then the only effect would be blocking the input thread until the draw frame finishes processing (unlike previously where it would pretty much deadlock).
We should eventually have better IRenderer API for this one way or another, but there's only one usage of this right now so let's get it in for the time being.
Tested to work with my setup, the rate of the display link callback (indicated by the draw FPS) changes correctly based on the display (as opposed to master where it gets stuck on the display the game was first launched in).
Incorporating @ILW8's work (ppy/veldrid#20) to more correctly provide hinting to metal as to where the window is running on the host, which allows better selection of refresh rates and display timings.
Tested on single display macbook and dual display mac pro (with two external displays). In these cases, I'm not noticing anything working better than before, but it runs fine without any signs of regression.
Closes #5828.