SFML freezes when mouse moves (VS 2010)

[conman420]

Hi,

Whenever I run my SFML program through visual studio 2010 (this also happens in 2008) and move the mouse rapidly on top of the window the whole game locks up completely and it uses 100% of the first core on the CPU, as soon as I stop moving the mouse the problem immediately stops.

Restarting visual studio sometimes fixes it for a bit and running the .exe file directly from windows explorer always makes the problem go away but it's getting really annoying.

This also happens in a blank sfml project with just a renderwindow and nothing else so it is not my code.

I have a Razer Deathadder mouse, my theory for why this happens is that the mouse is sending events to the window faster than it can process them causing a build up of events? But that's just speculation.

I hope someone else has come across this problem it's making me feel like my games running slowly when it is just the mouse!

Specs:

Intel Dual Core 2.66Ghz
4GB Ram
Windows 7 64 bit
NVidia gtx 260

Thanks.

Update: Just did some tests printing out how many events are being processed

If Visual studio is running and I move the mouse I get 250 events per frame and it freezes. However if I run it without visual studio (directly clicking the exe) I get a maximum of 1. This is very strange, I'm going to try and figure out if these events are all mouse movement events or if something else is creeping in there that shouldn't be.

PS. Sometimes the event count reaches the thousands if I move the mouse fast enough.

[Laurent]

I have a Razer Deathadder mouse, my theory for why this happens is that the mouse is sending events to the window faster than it can process them causing a build up of events? But that's just speculation.

Could be possible, but then it would also happen when you run the executable from the explorer, not just from Visual Studio.

Update: Just did some tests printing out how many events are being processed

If Visual studio is running and I move the mouse I get 250 events per frame and it freezes. However if I run it without visual studio (directly clicking the exe) I get a maximum of 1. This is very strange, I'm going to try and figure out if these events are all mouse movement events or if something else is creeping in there that shouldn't be.

Oh, ok
Let me know if you can find something.

[conman420]

Just did a test to see if they were all mouse movement events. Pretty much all of them are. Any ideas why running visual studio would increase the mouse movement events by 100 fold?

Lowering mouse dpi and polling rate does nothing to.

Code: [Select]



#include <iostream>
#include "SFML/System.hpp"
#include "SFML/Graphics.hpp"

int main()
{
    // Create the main rendering window
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
   
    // Start game loop
    while (App.IsOpened())
    {
        // Process events
        sf::Event Event;

int Test = 0;
int Test2 = 0;

        while (App.PollEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();
if (Event.Type == sf::Event::MouseMoved)
Test += 1;
Test2 += 1;
        }

std::cout << Test2 - Test << "\n";

        // Clear the screen (fill it with black color)
        App.Clear();

        // Display window contents on screen
        App.Display();
    }

    return EXIT_SUCCESS;
}


Code just in case I am being retarded.

Edit: Just did a test on a hello world program. No slow downs, was probably never going to do anything but I thought I would just eliminate the possibility of it not being SFML at all.

[Floomi]

I too am seeing this, in VS2005 / SFML2.

[Laurent]

Just did a test on a hello world program. No slow downs, was probably never going to do anything but I thought I would just eliminate the possibility of it not being SFML at all.

You should rather try an application with a window that catches mouse move events. But using native Win32 code, or another library such as Qt.

[conman420]

Sorry for the bump, but I had a slight development.

The bug goes away when I change the size of the renderwindow from whatever it was when the bug started to appear (in the case of my engine 800 by 800) to something else.

If I then change the screen size back to 800 by 800 the freezing is gone but it eventually comes back.

This is bizarre and I can't really find any sort of pattern, I have been having a few RAM issues lately and this could be some weird manifestation of faulty RAM but I just thought I would update the thread in case anyone is seeing the same thing.

[asveron]

Hi i had the same problem but I finally found the problem!!!

App.PollEvent causes sfml to read the mouse movement too much.

I guessed it by reading this:
http://www.gamedev.net/topic/575371-sfml---quick-mouse-movement-lags-input/

Usually we have App.PollEvent copied from the SFML default set up to close the window.

Code: [Select]


Event Event;
while (App.PollEvent(Event))
{
// Close window : exit
if (Event.Type == Event::Closed)
{
App.Close();
}
}
//QUIT
if(Keyboard::IsKeyPressed(Keyboard::Escape))
{
App.Close();
}


[Senzaki]

Hi,
It seems that this problem is still not corrected I'm using Linux, and everytime I use pollEvent, there are SO MANY events that are generated when I move the mouse (sometimes more than 100 in one frame). Wouldn't it be possible to give the option to synchronize pollEvent() and display() ? I mean, is it possible to generate only one "global" mouseMove event (that would be the addition of all mouseMove events) per frame ?

[Grimshaw]

I'd like to ressurect this thread as this problem was verified while someone tested my application.

http://www.mediafire.com/download.php?b6rvmtwtnwx9pj1

That's an actual windows binary in which the problem persists for some users. It may help identify the problem. Its a very simple program, which polls all events correctly from the sf::RenderWindow, and doesn't even do anything with sf::Event::MouseMoved.

Any ideas what can it be? It was reported to me that the game would not draw as long as the mouse is moving inside the window. He was using Win7 64 bit.

[Laurent]

Is it exactly the same problem, i.e. it appears only when running the app from Visual Studio and not from the explorer?

[Grimshaw]

He is just running binaries in release mode. I am compiling them in a Windows 7 32 bits, Visual Studio 2010

[Luponius]

Since I was the one who got this problem when running Grimshaw's files I'll explain the exact scenario.  As mentioned by Grim, it was the release version, not the VS10 environment.  However, I am on Win7 64bit, not 32.

Additionally, the application works "perfectly fine" even while moving the mouse, besides the actual drawing.

That is to say, I can left click to spawn circles, right click to spawn particle boxes or w/e and the console provides this output, even while doing this and moving the mouse.  However moving the mouse completely halts the rendering, even though updates are clearly still happening (objects still being created and physics is still being worked out).

I can spend 1 minute spinning the mouse about (freezing the screen throughout) and as I left and right click, the console provides prompts.  Once stopping mouse movement I'll see all the objects spawned neatly stacked up at the bottom, waiting for some other kind of event.  So I guess the question is: How is moving the mouse somehow "skipping" the draw method?  Maybe the source code could shed some light.