Mouse movement causing framerate drop

[Brendon]

I'm wondering if anyone else has seen this before: a lot of my users are reporting that when they move the mouse around, the game framerate drops to what seems like 1 fps.  If the user doesn't move the mouse, the framerate returns to the expected ~60.

The problem is that this is very inconsistent across machines, making it difficult to debug. I never get it on my dev machine, some others always have it, and for others the problem goes away after restarting the computer.

The input code is very straightforward:

Code: [Select]

public void Update(float elapsedTime)
{
      this.App.DispatchEvents();

      this.mouseX = this.App.Input.GetMouseX();
      this.mouseY = this.App.Input.GetMouseY();
}


I'm using the sfml dotnet 1.6 build.

Anyone have any thoughts on why this is happening?

[Laurent]

I have absolutely no idea, sorry. This is really weird.

Is this happening on Windows only? Have you been able to test it on other platforms?

[devlin]

What does your mainloop look like?

It could be that their computers are "drowning" in events from the mouse movement and thus it's just looping through those events instead of updating your game.

[Groogy]

I'm wondering, wouldn't a high-dps mouse generate more mouse movement events than what a low-dps mouse would generate?

Just thinking on that it varied from different computers.

[Brendon]

@Laurent - my game is available on pc, mac, & linux; I've only heard the issue reported on the pc.

@devlin - Can you explain a bit on how one would do that?  I figured DispatchEvents() is what updates all the events, and I'm only calling that once per frame.

@Groogy - that's an interesting idea - I'll ask my users if they have special mice.

I also found these other thread regarding mouse movement & framerate drop, but the issue seemed to have been fixed in his case-
http://www.sfml-dev.org/forum/viewtopic.php?t=2394

[devlin]

Well - I haven't looked at the DotNet bindings for SFML - but I do know that Application.DoEvents() will suspend the current thread while processing all waiting window messages.
Unless of course the DotNet bindings use PInvoke of the Peek/Translate/DispatchMessage instead of DoEvents to limit the amount of messages processed any one frame.

I bet Groogy is onto something - high dpi mice generate an awful lot of WM_INPUT messages, if any substantial work is done on those messages - it will slow things down.

[Laurent]

Well - I haven't looked at the DotNet bindings for SFML - but I do know that Application.DoEvents() will suspend the current thread while processing all waiting window messages.
Unless of course the DotNet bindings use PInvoke of the Peek/Translate/DispatchMessage instead of DoEvents to limit the amount of messages processed any one frame.

SFML.Net's DispatchEvents function calls the GetEvent function imported from SFML, which internally uses Peek/Translate/DispatchMessage. But there's no limit, it processes all messages.

I bet Groogy is onto something - high dpi mice generate an awful lot of WM_INPUT messages, if any substantial work is done on those messages - it will slow things down.

WM_INPUT is not caught by SFML, so if something happens there it's internal to Windows.

[Brendon]

Some of my users are using high-dps mice - if I were to make a test executable for these people, is there some way I can somehow limit the amount of events received per frame?

[Laurent]

No, you can't.

[Tank]

Actually he can, like this:

Code: [Select]

unsigned int catched_events( 0 );

while( window.IsOpened() ) {
while( catched_events < 10 && window.GetEvent( event ) ) {
// ...
++catched_events;
}

catched_events = 0;

// ...
}


I think those mice really can be the problem. Do you have any idea how many messages they generate per second?

[Laurent]

He can limit the number of mouse events he processes, but not those processed by SFML.

Do you have any idea how many messages they generate per second?

That should be the first thing to test, before investigating further in this direction

[devlin]

Movement should generate at least one message * CPI for every inch the player moves the mouse. Some of the newer mice are 5500+ "DPI"... which could easily flood a message loop if they move the mouse more than a few inches at a time - if the eventhandling is non-trivial and their computers slow.

[Brendon]

Counting how many messages are generated per second sounds like a good place to start.  Here's my test app:

Catch the events when user moves mouse:

Code: [Select]

appWindow.MouseMoved += new EventHandler<MouseMoveEventArgs>(appWindow_MouseMoved);

Increment a counter each time the mouse moves:

Code: [Select]

void appWindow_MouseMoved(object sender, SFML.Window.MouseMoveEventArgs e)
{
       this.mousemoveCounter++;
}
Once per second, display mousemoveCounter's value before resetting it to zero.

Does that sound like how one would count the messages per second?

[Brendon]

I set up the event-test program.  

My mouse gets ~125 mouse-movement events per second. My user with the problem is getting ~500 events per second.

For those curious, here's a link to the program: http://blendogames.com/dev/windowtest04.zip

[Groogy]

500 still looks like a bit low to actually make the application lag. Though depends on the host machine and what you actually do with the event.

Easy fix for Laurent is to add a bool to mouse moved event that tells the end user if this is the last mouse moved event currently in the queue. Giving us the option to:

Code: [Select]


while( window.GetEvent( event ) == true )
{
        switch( event.Type )
        {
         case sf::Event::MouseMoved:
                if( event.MouseMove.IsLast == false )
                        continue;
        }
}


Unless you depend on precise relative movement, this should help out with the lag as you now instead just ignores all mouse movement that you anyway don't care about.

High DPI mices are a joke. They slow down both the hardware and the software <_< (Clogging up traffic unnecessary)
Why do people buy them?