Vsync in the renderer seems to be non-functional in macOS Mojave with SDL 2.0.8 and the pre-release of 2.0.9. At least on my MacBook Pro with Intel HD Graphics 4000. It works fine with macOS High Sierra.
Is this because of the removal of OpenGL, and will it be fixed in future versions of SDL2?
1 Like
Itās just broken right now; we arenāt sure if itās a Mojave bug or what at the moment.
Iām going to try to follow up with Apple and see what I can find out.
Vsync works in Metal, so itās not a global failure of vsynciness on the platform.
Is there a plan to make Metal the default on macOS Mojave and later?
For the 2D render API, yes, but apps using OpenGL still suffer. Iām looking at playing with Appleās DisplayLink API to see if we can get vsync working on GL again.
Adding some observations since I upgraded to MacOS Mojave and working on a game that uses OpenGL.
I was getting the black OpenGL window, but upgraded to 2.0.9 and works fine. (Thanks!!!)
Now contending with a lack of vertical sync on Mac. I did some tests with a testbed appā¦
-
Drawing just a few polygons means the app can easily hit 300+fps. Turning vertical sync on/off has no effect.
-
Just a few polygons with a SDL_Delay(1000/60) runs at 50fps, no frame drops.
-
(the interesting case) If I throw 100x the polygons then the app ārunsā at 30fps but Iām getting some serious frame skip/drop with it only showing every 2nd/3rd/4th frame so it looks like itās running 10fps or less.
Is there something going on under the Mac hood causing frame drops when the rendering gets heavy that anyone else aware of?
No problems on any other platform (Win, iOS).
Additionalā¦
I turned off rendering some background buildings and now Iām not getting any frame drops. So thereās definitely some threshold of drawing stuff that triggers Mac OpenGL to start tripping over itself and start dropping bunches of frames.
As a short term development only hack fix itās fine, but obviously not a long term release option.
My (current, possibly incorrect) understanding is OpenGL+vsync is broken in Mojave. Vsync for Metal works, but the āswap intervalā API in NSOpenGLContext just doesnāt work. We might be able to fake this ourselves with CVDisplayLink, but I havenāt tried yet.
So OpenGL is the default on macOS when you are creating a renderer, then? Iām not selecting the OpenGL driver intentionally at all, and I still get no vsync after setting up the renderer (used with a streamed texture as the framebuffer, and the vsync flag).
So far, even in 2.0.9. In 2.0.10, weāll likely make Metal the default (and fallback to OpenGL on older macOS releases). Alex has done a ton of work on the Metal renderer, and I think itās pretty solid now.
Do you happen to know whether Metal has any equivalent to OpenGLās āglLogicOpā functionality? I need to be able to set AND, OR and XOR plotting modes which for the moment forces me to use OpenGL irrespective of the merits of any other renderers.
I think thereās just one or two things missing before Iād consider it production-ready: we donāt have a LockTexture implementation yet, and UpdateTexture can replace the texture in a previous frame if you do it too quickly. I have ideas for both of those though, hopefully theyāll get resolved Soonā¢. 
Metal doesnāt have an equivalent to glLogicOp: https://openradar.appspot.com/34763016
On iOS it could theoretically be implemented via a custom shader (due to iOSā ability to have fully programmable blending), but not on macOS.
What are you using it for? I wonder if thereās a different solution to the problem youāre trying to solve.
My app is an interpreter for the BBC BASIC programming language. BBC BASIC supports OR, AND and XOR plotting via the GCOL statement, which is commonly found in programs written in that language.
The only alternative to using glLogicOp() would be to read the display buffer with SDL_RenderReadPixels(), modify the pixels myself, and then write the buffer back. But I would expect that to be far too slow.
This is good to hear. Iām doing a game that does a lot of its own drawing and then uses the accelerated renderer to put that on the screen, and itāll be nice to have LockTexture working in Metal.
FWIW can I emphasise how important it is to me to find a workaround. I canāt use Metal, for the reasons I explained, so Iām completely dependent on continued support for OpenGL via SDL2 on MacOS. Some people have expressed the opinion that, having been deprecated, OpenGL will inevitably be removed completely; but we donāt know that and I wouldnāt want it to be used as an excuse for not solving the vsync problem.
If you really need it fixed you should probably file a bug with Apple using their radar bug tracker.
Ryan said earlier in the thread that he was following it up with Apple. But continuing to pursue a workaround in SDL seems sensible as well.
I wonder if one workaround to get VSYNC working with OpenGL rendering could be achieved by using Metal as only the final buffer render by following the Mixing Metal and OpenGL documentation. Not sure it would help anything, but might allow OpenGL-specific stuff to work while possibly rendering as if using Metal such that VSYNC would work (Mojave build w/XCode 10 - or probably more accurately 10.14 frameworks).
The best paths forward of course are to get Apple to fix the issue and default to full Metal rendering, but maybe for those who require OpenGL with the presumption Apple never fixes it ā¦ ?
I havenāt yet āupgradedā to Mojave so cannot confirm this for myself, but a report received from a user states that my app (which is currently 32-bit and built on MacOS Snow Leopard!) runs at a solid 60 fps, which suggests to me that vSync is actually working. I suppose itās possible that itās broken only for 64-bit builds (and of course MacOS is dropping support for 32-bit apps soon) but this observation is at least āinterestingā.
@rtrussell I believe the issue exists in the 10.14 frameworks/SDK since vsync works fine when building on Mojave with XCode 9.4.1 (10.13 SDK) and running the game .app on Mojave. Both builds are 64-bit, so while it is the case that itās only the 64-bit builds are broken, that might be due to the 10.14 SDK not being available for 32-bit. I havenāt yet tried building with XCode10 & 10.14 SDK on High Sierra and then running that product .app on Mojave, but probably not worth the effort at this point.
You make a good point that the smarter workaround is to probably just use Xcode 9.x until Metal is fully supported (or for all games that require supporting OpenGL on Mac).
(aside: I couldnāt quickly get Xcode 10 to build w/10.13 SDK to test that combo, granted I put in a minimal effort)