Hacker News Reader

Comment by jchb | Hacker News Reader

If you use OpenGL or Metal with triple buffering (the blog post mentions MTLView which is a Metal view) I believe this doesn't matter. You'll only be using the CVDisplayLink timer events to generate frames spaced at a even interval - which is equal to the display vsync interval, depending how you configure CVDisplayLink. Then, the actual presentation of those frames will happen in sync with the actual display vsync.

See Metal Triple Buffering (https://developer.apple.com/library/content/documentation/3D...) and MTLCommandBuffer presentDrawable.

For OpenGL there are similar mechanisms, eg. NSOpenGLCPSwapInterval.

View on HN

If you're aiming for the lowest latency possible, you will still want to have access to the actual display refresh timing information. But these days with variable refresh rate monitors growing in popularity, this gets pretty complicated.

Does Apple even support any of the variable refresh rate standards?

Not sure about Apple, but on a hackintosh you can install Nvidia Geforce drivers that allow you to turn on GSync.

Which is kinda buggy last I checked, crashing if more than one display was attached.

If you set the swap interval to 1, my recollection is that glFlush() (or -[NSOpenGLContext flushBuffers]) will block until the frame is presented. I’ve never relied on that behavior, but I’ve always wondered if the display link timer was even necessary, or if you could just use a while loop.

What's the scenario where you would want to do that? I understand there's a (theoretical?) scenario where you want to minimise latency between screen rendering (or input handling?) and presentation. But if you use double buffering, which a while loop that block until the frame is presented, then the CPU will sit idle while the GPU is doing it's work. Instead of preparing the next frame after that - which may result in the CPU preparing the next screen too late if the scene complexity is fluctuating.

Reply on news.ycombinator.com