| Summary: | SDL_PollEvent performance decreased in 2.0.10 compared to 2.0.8 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Dennis Felsing <dennis> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | blocker | ||
| Priority: | P2 | CC: | cameron.gutman, iryont, stfx, sylvain.becker |
| Version: | 2.0.10 | Keywords: | target-2.0.12 |
| Hardware: | x86_64 | ||
| OS: | Windows (All) | ||
| Attachments: | Visual Studio debugging output, left side SDL 2.0.8, right side SDL 2.0.10 | ||
|
Description
Dennis Felsing
2019-12-13 22:40:47 UTC
Hello, Maybe you could re-compile latest version and see if this is really the case ? The logging seems only checking one variable, which should be fair, provided logging isn't actually enabled. It looks like you don't have PDBs for the SDL builds you're using, which is probably why you aren't having much luck with the VS profiler. If you build SDL yourself using the VS projects, you should get the PDBs you need to make the profiler output useful data for functions inside SDL2.dll. It's not surprising that SDL_WaitEventTimeout() is showing up hot in the profiles. It internally calls SDL_PumpEvents() which triggers basically all of the logic used to generate SDL_Events (processing OS window messages, polling for new input on input devices, polling for newly attached or detached joysticks, etc.) Do you have a way of showing FPS? Also, there was a known issue in 2.0.10 release, does it work better if you try a newer DLL? http://www.libsdl.org/tmp/SDL-win64.zip (In reply to Cameron Gutman from comment #2) > It looks like you don't have PDBs for the SDL builds you're using, which is > probably why you aren't having much luck with the VS profiler. If you build > SDL yourself using the VS projects, you should get the PDBs you need to make > the profiler output useful data for functions inside SDL2.dll. Unfortunately I don't have Windows/VS in order to build myself. But thanks for the explanation. (In reply to Sam Lantinga from comment #3) > Do you have a way of showing FPS? F1, cl_show_fps 1 (In reply to Sam Lantinga from comment #3) > Also, there was a known issue in 2.0.10 release, does it work better if you > try a newer DLL? > http://www.libsdl.org/tmp/SDL-win64.zip I will give this a try later today, thanks for the hint. (In reply to Dennis Felsing from comment #4) > (In reply to Sam Lantinga from comment #3) > > Also, there was a known issue in 2.0.10 release, does it work better if you > > try a newer DLL? > > http://www.libsdl.org/tmp/SDL-win64.zip > > I will give this a try later today, thanks for the hint. Unfortunately no difference. I'm not able to reproduce this. I get 790-800 FPS with 2.0.8, 2.0.10, and 2.0.11 DLLs. Can whoever is doing the profiling download the latest SDL code and build it themselves with Visual Studio so you can get more detailed profiling information? http://www.libsdl.org/tmp/SDL-2.0.zip Thanks! Since this was relevant to me I just tested it on the SDL implementation of imgui and also cannot see any performance regression between SDL 2.0.8 and SDL 2.0.10 when compiled as release build with MSVC on Win10. I had no periphericals other than a wireless USB mouse connected to my laptop. No issues here either. I'm reaching 3500 fps in my game resulting in about 285 us per frame during which SDL_PollEvent is called. Created attachment 4208 [details]
Visual Studio debugging output, left side SDL 2.0.8, right side SDL 2.0.10
That's perfect, thank you! I believe this was just fixed in the latest snapshot: http://www.libsdl.org/tmp/SDL-2.0.zip Under what circumstances this could be replicated? I've been using SDL2 in a highly responsive application (game) and I had no reports of such issue. This would happen if you have the mouse grabbed or in relative mode. Tested, verified fixed. |