Speed issues with Joystick event processing

[Fray]

Hello,

I'm still having this weird problem where joystick polling drastically slows down the game (huge fps drop, stuttering, etc). I'm using the basic while loop to poll events, nothing too fancy.
The problem disappears if I comment out the ProcessJoystickEvents() call in WindowImpl.cpp

Chances are it's a problem on my side, but I'm wondering if anyone had experienced the same issue and maybe knows how to resolve it.

Here's what I get after quickly profiling a minimal sfml app:
http://img703.imageshack.us/img703/9109/sleepyk.png

I'm using win7, lastest SFML2, VS2010

Thanks

[Laurent]

Is it slow even if you have no joystick connected?

Does it disappear if you put a "return false" at the beginning of JoystickImpl::IsConnected, in src\SFML\Window\Win32\JoystickImpl.cpp?

[Fray]

Is it slow even if you have no joystick connected?

Does it disappear if you put a "return false" at the beginning of JoystickImpl::IsConnected, in src\SFML\Window\Win32\JoystickImpl.cpp?

It's slow even with no joystick connected, but the problem indeed desappears if JoystickImpl::IsConnected doesn't do the joyGetPosEx() stuff.

Cheers

[Laurent]

Ok, thanks.

I really need to find another way of testing joysticks.

[mbro2k]

I think I may have a related issue.

When I turn on my xbox gamepad in windows before starting
my game, the game runs choppy for about 15 seconds or so
and then goes back to normal for good.  

This only seems to happen during
the first time connecting the gamepad, and it only happens when
using a gamepad.

I'm using sfml2 from late september(0fd992d) and windows 7.

I think this wasn't happening in older versions of sfml2 I was using(49c0208).

[mbro2k]

I found a solution for my particular problem over in general

http://www.sfml-dev.org/forum/viewtopic.php?p=40190#40190

[novemberdobby]

Sorry to bump an old topic, but I also had this problem and discovered a different solution.

I modified JoystickImpl::IsConnected to use XInput instead of JoyGetPosEx, and there's no longer any lag. I was getting huge spikes when triggering mouse move events on my SFML window, particularly when a gamepad was recently unplugged (even after restarting the program).


This probably only works for Xbox controllers as I haven't got anything else to test it with, but here's what I changed:

src\SFML\Window\Win32\JoystickImpl.cpp

Code: [Select]


#include <Xinput.h>
...
bool JoystickImpl::IsConnected(unsigned int index)
{
    //removed joyGetPosEx stuff

    XINPUT_STATE dummy;
    ZeroMemory(&dummy, sizeof(XINPUT_STATE));
    DWORD result = XInputGetState(index, &dummy);
    return result == ERROR_SUCCESS;
}


But it allows you to poll the connection state as often as you like with no slowdown.

[Laurent]

Since XInput is only for XBox controllers, a solution using DirectInput would be better

[speps]

After some weird slowdowns happening, I did run xperf on our game and I found out that 15% of CPU is spent polling for joysticks (which we do not support directly, we use XInput outside SFML).

Here is a proof screenshot :



I was wondering if you could move the code for polling joystick to the raw input interface (sf::Input) and don't clobber the other event based path? This way, people wanting joystick input would suffer but other developers would not have to worry about this.

If I find something that works well, I could do a pull request.

Cheers,
Remi Gillig.

[speps]

I did the source modification you recommended here [1]. Here is the pull request [2].

I started a discussion about the use of SetThreadAffinityMask there, I would like to know if this change could be possible in the future. It seems a big overhead for something which should be specific to only some games.

[1] http://en.sfml-dev.org/forums/index.php?topic=6079.0
[2] https://github.com/SFML/SFML/pull/210

[Laurent]

Well, SetThreadAffinityMask is used everywhere (Ogre3D, Qt) and it doesn't seem to be a problem.

[origon]

Hello,
I am also battling with very slow event processing, could be related.
SFML 2.0
The packaged examples (.exe's) (and my own programs) come to a halt when i move the mouse cursor continiously over the active window. It seems that the event queue is filling faster than it is being read. Same effect if i spam keystrokes.
(Windows - MinGW (Code::Blocks) (16.1 MB))
Windows 7

I tried running the examples at work, with no event problems. (XP)

[speps]

Well, SetThreadAffinityMask is used everywhere (Ogre3D, Qt) and it doesn't seem to be a problem.

I'm only basing this on the profiling I did, in my patch for checking connection only every second, I use sf::Clock and this made "SetThreadAffinityMask" appear in the top functions at around 9% of total CPU time over the sampling period. So instead of having joyGetPosEx at 16%, it makes SetThreadAffinityMask jump to 9%. Maybe because it checks for every possible joystick and should only check it once, I will try to do a different match if I find time this weekend.

[pdinklag]

I just hit into this problem, also using XBox controllers.
My event handler is virtually flooded with joystick move events, but apparently the polling itself has performance issues?

Is it possible to tell SFML to not listen for joystick move events? Polling the axis positions seems to work fine, and that's really all I need.

Furthermore, is it safe to poll / wait for events (in general) in another thread and add them to a queue to be processed in the main loop? That way I could filter joystick move events as a workaround. It might cause slight input lags, but at least the framerate doesn't drop.

[Laurent]

My event handler is virtually flooded with joystick move events, but apparently the polling itself has performance issues?

This is not the same problem. The initial problem was just a performance issue, no extra events were triggered.

What do these events contain? Is it always the same position, almost the same, or a random one? Does it happen when you don't move the axis at all? Have you tried to play with setJoystickThreshold?