Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - speps

Pages: [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.

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

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.

Remi Gillig.

Pages: [1]