This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Code file demonstrating a case where the stutter can appear. (main.cpp, text/plain, 2018-12-06 20:17:30 +0000, 1142 bytes)

Reported in version: 2.0.9
Reported for operating system, platform: Windows 10, x86

Comments on the original bug report:

On 2018-12-06 20:17:30 +0000, wrote:

Created attachment 3536
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.

On 2018-12-07 18:40:53 +0000, wrote:

Issue appears to be solved by https://hg.libsdl.org/SDL/rev/9091b20040cf under the same test conditions as this report.

On 2019-07-30 17:49:36 +0000, Ryan C. Gordon wrote:

(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.

On 2019-08-03 00:03:09 +0000, Daniel Gibson wrote:

the reporter said it's resolved (another instance of the Windows+HIDAPI bug fixed in 2.0.10) so this can be closed

On 2019-09-20 20:47:36 +0000, Ryan C. Gordon wrote:

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.

On 2019-09-20 20:48:38 +0000, Ryan C. Gordon wrote:

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.