-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workaround against SDL_GetPerformanceCounter that sometimes stalls #6114
Conversation
bb373e8
to
5cf4e0c
Compare
Under emscripten, consecutive calls to SDL_GetPerformanceCounter() might lead to the same result, which will result in IM_ASSERT(g.IO.DeltaTime > 0.0f) to fail later, inside ImGui::ErrorCheckNewFrameSanityChecks() We store the last positive DeltaTime in a static variable and return this if a stall is detected.
5cf4e0c
to
6eb4e95
Compare
Hello Omar,
Absolutely! I added an ifdef, and reused the previous value when a stall is detected. FYI, this issue happens once every 600 frames or so on Safari/macOS, so that on my side an emscripten app has an average survival time of 10 seconds :-) |
What's your average framerate in that app? In your situation (rare/occasional 0.0f) it seems like using the smallest values (e.g. 0.00001f) may be more correct than last DeltaTime. |
My app average framerate is 60fps.
I will try to study that. No that easy though, since any slight instrumentation might change the behavior (this bug might disappear depending on the compilation etc. It seems more present when the application is heavy. Eek...)
Right While I have your attention, during these last months, I discreetly worked on a library around ImGui which group various libraries from the ecosystem, and enables to easily create ImGui applications in C++ and Python. If you have time, here are some links to it: Cheers! PS: my apologies if you feel like I tell you about this library too late, I wanted it to be nice looking and a bit battle tested before going further. |
Thanks! I have noticed this in the past few weeks (I have your remote showing in my git ui as I'll try to resume work to facilitate imgui_manual and other things0. It looks great and will share it now that you've announced it (will also add to wiki etc.) (PS: consider calling it "Dear ImGui Bundle" when referred to strings/text form, outside of code/namespace ;) |
PS.2: I added it to wiki + made a public post, but feel free to post in Gallery! (and we'll mention it in next Release Notes) |
I have thought about this PR and my conclusions are:
Even in the worst case of #3644 (one 0.100 ms, three 0.000 ms) it seems like this would make the issue less prominent. Thanks for this! |
Hello,
Thanks! This will simplify my code :-) PS: I posted a message about it in the gallery yesterday. I'm a bit worried, because I saw no reaction to this message. I hope it was not perceived as me showing off too much in the wrong place, as it was not my intention at all. Cheers! |
Hello, Just a rather technical information about this issue: I very much suspect that the fact we sometimes get a timer that stalls is due to mitigation measures against attacks using Spectre. The high precision clock accuracy is reduced by default with WebASM, unless COOP and COEP headers are sent. See https://web.dev/why-coop-coep/ |
… a monotonically increasing value. (ocornut#6189, ocornut#6114, ocornut#3644)
… a monotonically increasing value. (ocornut#6189, ocornut#6114, ocornut#3644)
This PR covers a quite uncommon corner case with SDL under emscripten.
Consecutive calls to SDL_GetPerformanceCounter() might lead to the same result, which will result in
IM_ASSERT(g.IO.DeltaTime > 0.0f)
to fail later, insideImGui::ErrorCheckNewFrameSanityChecks()
This happens only under emscripten, and with specific javascript engines (it is quite common with Safari under macOS, but does not happen with firefox under macOS).