SDL_HINT_RENDER_VSYNC=1 results in half of the expected refresh rate on emscripten/web

[neonmoe]

I'm using the Rust bindings for SDL3 in my application, and it's using the SDL3 main callbacks (init/iterate/event). I'm deploying the application by compiling it for emscripten, using the -sUSE_SDL=3 emscripten port.

With vsync disabled (via simply not setting the SDL_HINT_RENDER_VSYNC hint), I'm getting ~240 FPS on a 120 Hz screen, while with vsync enabled (via setting the SDL_HINT_RENDER_VSYNC hint to "1"), I'm getting just 60 FPS (!!). It seems like requestAnimationFrame is being used when vsync is enabled, which looks good, but there's apparently some sleeping happening in RenderPresent in addition to that? My guess is that the sleep is throttling down the FPS to 60 from the 120 requestAnimationFrame would end up at, but I'm not sure. But in any case, I wouldn't expect any additional sleeping if we're already using requestAnimationFrame to drive the main loop.

I haven't looked into the code yet, this is just based on looking at Chromium performance profiles:

Now, while it looks to me like a bug, I understand that it might be that the sleep is intended to "line up" with requestAnimationFrame and it's not actually throttling it, so this is kind of a hybrid question/bug report issue: is this a bug, or should I be looking into why the sleep/rAF ends up being so long with my setup?

[neonmoe]

Bug-or-not-mystery solved: I just commented out the present, and it's still only running at 60 FPS. I suppose it's just the browsers being slow! Nope, see next comment.

[neonmoe]

Unfortunate, I suppose I can't reopen the issue, (thanks!) but in the classic manner, right after declaring this diagnosed, I had the thought to test with another browser, and with Chromium it the RenderPresent appears to be the throttle: with present commented out, it's 120 FPS, with it in, 60 FPS. Firefox is 60 FPS in both cases. (EDIT: Even better, firefox appears to get up to 120 FPS too, with present commented out, but only after switching tabs and coming back to it... Love browsers.)

So I think there might be a bug here after all.

[neonmoe]

I've explained the reasons further in the PR, but in case anyone else needs to work around this, emscripten_set_main_loop_timing(EM_TIMING_RAF, 1) before creating the renderer seems to work for me. The issue hinges on the emscripten main loop timing mode not being RAF by the time vsync gets enabled, so setting it to RAF ahead of time makes it work out as expected.