Why does FPS not match slow rendering?

[esotericpig]

Hi, I'm using SDL2 and Emscripten.

I use SDL_GetTicks64() for measuring FPS and draw it to the screen. On desktop, it works perfectly fine.

In Google Chrome, I decided to test with "graphics acceleration" off and use software.

As expected, the rendering is very slow, but I was surprised to see the FPS still at 200.

I tried using SDL_GetTicks() and emscripten_get_now() instead, but the FPS still shows as 200, while graphics rendering is extremely slow.

As a desktop app, I tested drawing tons of stuff and can get the FPS to drop or increase appropriately.

What's going on here? Does Google Chrome put all of the rendering in a separate thread? And then it's not affected in SDL_GetTicks/emscripten_get_now?

I use 0 in the FPS param of emscripten_set_main_loop().

Is there an option to force async off for rendering? I don't use multiple threads in my C++ code.

[kripken]

Browsers generally draw the screen at 30 or 60fps (updated from a graphics process, independent from the CPU processes), while CPU operations might be executing a lot faster. That might be related to what you see, but "very slow" sounds like maybe more is going on?

[esotericpig]

I'm sorry. I think I figured something out. I believe it has to do with Uint64/double conversion/precision. If I allow a high 200 FPS, it works perfectly fine in desktop app, but not in web browser. I thought it had to do with async rendering, but doesn't seem to be the case, as when I restrict the FPS to 60, it now runs fine.

My guess is that it has something to do with Uint64/double conversion/precision. Here's a basic outline of what a single frame looks like for me:

//run_emscripten_frame() -- runs a single frame
Uint64 start_ticks = SDL_GetTicks64();

// do everything: input, logic, draw/render

Uint64 end_ticks = SDL_GetTicks64() - start_ticks;
double millis_per_frame = static_cast<double>(end_ticks); // Simulates my Duration class.

if(millis_per_frame < target_millis_per_frame) {
  SDL_Delay(static_cast<Uint32>(std::round(target_millis_per_frame - millis_per_frame)));

  // Update for delay.
  end_ticks = SDL_GetTicks64() - start_ticks;
  millis_per_frame = static_cast<double>(end_ticks);
}

double delta_time = millis_per_frame / 1000.0; // Convert to seconds.

If I use a high target FPS, such as 200 FPS (1000.0 / 200 = 5.0 millis/frame), then it runs fine and smoothly in desktop app (and can see the FPS at 200), but in web browser, it's awful. My only theory is that this is from all of the casting/division/etc.

But after changing the FPS back to 60 after testing, it now works fine. I guess 60 FPS doesn't cause a loss of precision or whatever for some reason. I'm not really sure.

[kripken]

uint64 and doubles should behave the same as on normal builds, so I don't have a guess here.

Perhaps try to narrow this down to a small testcase you can share. Another option is to run the browser profiler to see what is taking time.

[esotericpig]

On my newer laptop, with "graphics acceleration" off in Chrome, I can't recreate it.

I can only recreate it on my old laptop (all software and OS [Fedora] up-to-date) with "graphics acceleration" off in Chrome.

I figured out a different way to fix it, just by moving my "stop frame timer" logic to beginning of run frame. So this:

stop_frame_timer(); // calculates delta time
start_frame_timer();

// all logic

Instead of this:

start_frame_timer();

// all logic

stop_frame_timer();

I believe it's a precision/conversion issue, an async issue, and/or a timing issue in Chrome/JS.

I was working on a test project to share, but decided it's too much trouble for something probably others can't recreate unless you have a low-end computer.