Messages

1

Window / Re: Speed issues with Joystick event processing

« on: April 20, 2012, 11:37:18 am »

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.

2

Window / Re: Speed issues with Joystick event processing

« on: April 18, 2012, 12:24:38 am »

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

3

Window / Re: Speed issues with Joystick event processing

« on: April 17, 2012, 10:12:52 pm »

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.