We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4417

Summary: SDL_PollEvent() microstutters every 3000ms due to general presence of USB devices.
Product: SDL Reporter: savetotheadrive
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: metalcaedes
Version: 2.0.9Keywords: target-2.0.12
Hardware: x86   
OS: Windows 10   
Attachments: Code file demonstrating a case where the stutter can appear.

Description savetotheadrive 2018-12-06 20:17:30 UTC 
Created attachment 3536 [details]
Code file demonstrating a case where the stutter can appear.

Steps:

1. Build and run code from attachment.

2. Focus on console output and let the SDL window idle.

3. Remove and add PnP USB input devices to your computer, making sure to watch the console output for effects.

4. Adjust line 33 to determine an appropriate watch for deltaTime, if necessary

Results:

Every 3000ms or so, a microstutter will happen depending on the type and amound of USB devices plugged in.  This stutter is indicated by an abnormally high deltaTime value (center column in console).

Expected:

Significantly reduced stutter, or none at all.


Issue found in Windows 10, with c++17 in VS2017 using SDL2-2.0.9


This issue does not appear to be present in SDL2-2.0.8

Additional Info:

In a simple game loop, microstutters are appearing at almost exactly 3000ms intervals.  I was able to trigger this on two separate Win10 machines(one of which has also seen this issue on a Win7 partition) with the attached .cpp file.

The amount of USB devices appears to determine the length of the stutter. Just a USB keyboard would cause around 50ms of lag, while a USB keyboard, mouse, and headset would cause close to 130ms. I would imagine that this would vary a bit here and there.

The lag appears to occur primarily during SDL_PollEvent().

See https://stackoverflow.com/questions/53644628/sdl-pollevent-stuttering-while-idle/53658644#53658644 for more details.
Comment 1 savetotheadrive 2018-12-07 18:40:53 UTC 
Issue appears to be solved by https://hg.libsdl.org/SDL/rev/9091b20040cf under the same test conditions as this report.
Comment 2 Ryan C. Gordon 2019-07-30 17:49:36 UTC 
(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.
Comment 3 Daniel Gibson 2019-08-03 00:03:09 UTC 
the reporter said it's resolved (another instance of the Windows+HIDAPI bug fixed in 2.0.10) so this can be closed
Comment 4 Ryan C. Gordon 2019-09-20 20:47:36 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 5 Ryan C. Gordon 2019-09-20 20:48:38 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.