This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Screen of profiling on SDL 2.0.12 (profiler-SDL-2.0.12.png, image/png, 2020-06-04 20:07:54 +0000, 103315 bytes)
• Screen of profiling on SDL 2.0.8 (profiler-SDL-2.0.8.png, image/png, 2020-06-04 20:08:42 +0000, 116698 bytes)
• More profile info (SDL_profile.png, image/png, 2020-06-07 03:00:29 +0000, 243321 bytes)

Reported in version: 2.0.12
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2020-06-01 14:18:37 +0000, Carlos Tobon wrote:

While working on a side project emulator, I noticed slow fps whenever using the PollEvent functions. I found someone having the same issue here on stackeoverflow:
https://stackoverflow.com/questions/58639564/why-is-sdl-pollevent-so-slow/62103973# 62103973

I verified this when profiling the application using VS 2019 on Windows 10, with most of the cpu time being spent in the PollEvent function. Following some suggestions in the comments I downgraded to 2.0.8 and the issue was resolved.

I only tested versions 2.0.9 and 2.0.12 and noticed that the issue is still present.

On 2020-06-04 05:28:13 +0000, Cameron Gutman wrote:

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.

On 2020-06-04 20:07:54 +0000, Carlos Tobon wrote:

Created attachment 4370
Screen of profiling on SDL 2.0.12

On 2020-06-04 20:08:42 +0000, Carlos Tobon wrote:

Created attachment 4371
Screen of profiling on SDL 2.0.8

On 2020-06-04 20:14:31 +0000, Carlos Tobon wrote:

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.

On 2020-06-07 01:58:28 +0000, Cameron Gutman wrote:

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.

On 2020-06-07 02:30:16 +0000, Carlos Tobon wrote:

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?

On 2020-06-07 03:00:29 +0000, Carlos Tobon wrote:

Created attachment 4374
More profile info

Additional profiling info

On 2020-06-07 03:02:38 +0000, Carlos Tobon wrote:

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.

On 2020-06-07 07:05:13 +0000, Dom wrote:

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

On 2020-06-10 04:48:42 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/ff702ce6ab48

On 2020-06-10 12:07:15 +0000, Carlos Tobon wrote:

Glad I was able to help! Thanks!

On 2020-08-09 11:31:06 +0000, Dave Lawrence wrote:

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)