| Summary: | PollEvent impacts performance in 2.0.12 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Carlos Tobon <jinzo2727> |
| Component: | joystick | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | cameron.gutman, dl, stfx |
| Version: | 2.0.12 | Keywords: | target-2.0.14 |
| Hardware: | x86_64 | ||
| OS: | Windows 10 | ||
| Attachments: |
Screen of profiling on SDL 2.0.12
Screen of profiling on SDL 2.0.8 More profile info |
||
|
Description
Carlos Tobon
2020-06-01 14:18:37 UTC
Do you have sample code that reproduces the issue? Can you post your profiling results? SDL_PollEvent() is going to be hot in profiles, especially if called in a tight loop like that, because that's where most of the event handling logic of SDL takes place. To get deeper than just SDL exports in your profile, you'll probably need to build SDL2.dll locally to ensure the PDB is available for the profiler. Created attachment 4370 [details]
Screen of profiling on SDL 2.0.12
Created attachment 4371 [details]
Screen of profiling on SDL 2.0.8
Hope this gives a better picture. Unfortunately this is what I can manage atm without building from src. If need be, I will try and see if I can do that over the weekend. Just want to point out that it becomes really fast when using 2.0.8 with no changes in the logic. and is broken from 2.0.9 and up. Unfortunately, without symbols for SDL it's impossible to determine from the profiling data where the problem is inside SDL_PollEvent(). Fortunately, SDL has pre-made VS projects which make it pretty simple to build. You're right, it was easy to build the project with the pdb. Just wanted to point out that in my particular scenario, I am using the c# bindings as well. Even with the pdbs for the bindings and SDL, I am not currently seeing any additional info when profiling. I do see that the symbols are being loaded. Do you have any other suggestions? Created attachment 4374 [details]
More profile info
Additional profiling info
Please see the latest attachment as I was able to drill down and it looks to be an issue with the GetClipCursor() in WIN_UpdateClipCursor(). Let me know if you need any other additional info. This seems to be Bug 4748. In SDL 2.0.12 this was tried to be fixed with https://hg.libsdl.org/SDL/rev/d5109d6a9b98 and https://hg.libsdl.org/SDL/rev/529fc1a611e8 which apparently didn't work. The original issue is caused by https://hg.libsdl.org/SDL/rev/2a9b4339468b in SDL 2.0.9. This is a deal breaker for me and many other people being forced to downgrade to SDL 2.0.8 again if they want to use relative mouse mode or mouse grab without performance issues. Please add this bug to target-2.0.14 Fixed, thanks! https://hg.libsdl.org/SDL/rev/ff702ce6ab48 Glad I was able to help! Thanks! Hi, We are seeing occasional unexpected 'long' pauses in SDL_PollEvent, we added a very basic timer around the call to try and catch these, reporting execution times longer than 10ms, here's a short snippet of output: 2020-08-07 17:10:38 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 16ms 2020-08-07 17:10:52 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 15ms 2020-08-07 17:10:56 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 16ms 2020-08-07 17:10:58 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 15ms 2020-08-07 17:11:02 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 15ms 2020-08-07 17:11:04 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 16ms 2020-08-07 17:11:10 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 16ms 2020-08-07 17:11:17 poll() SDL_PollEvent return 0, event type 0 - limit 10ms - duration 16ms ... so every few seconds, but not at regular intervals. Could this be the same issue as reported here? (Windows10/SDL2.0.12) |