Polling events and setting cursor position thread safety

[Groogy]

Oi!

I'm just wondering if it is thread safe to pull events in one thread and set the cursor position in another thread? This is in SFML2 of course.

Because of the recent changes it feels like they are being detached more and more from each other so I suspect they got nothing to do with each other but just want to make sure before I change anything in my engine.

[Laurent]

In today's revision, they really are disconnected from each other so it's safe to use them concurrently.

[Groogy]

One problem though... Whenever I move my mouse... The entire application locks until the mouse stops... At least that's how it is for my example application on the engine... Is there something in SFML that creates this behaviour or is it me doing something funky?

[Laurent]

Hmm I don't know. Try to reproduce it in a minimal SFML-only application.

[Groogy]

Apparently the lock don't happen if I comment out:

Code: [Select]

sf::Mouse::SetPosition( sf::Vector2i( myWindow.GetWidth() / 2, myWindow.GetHeight() / 2 ), myWindow );

If you are not doing any locking then Windows probably are... I'll try and find a work around. But seriously, dude we need a better way to create a FPS camera or something.

Update: Or wait.. might be something else.. though funny thing is when the mouse is OUTSIDE the window it don't lock =/

[Laurent]

If you SetPosition and PollEvent in parallel, then the latter can be spammed by the former and your event loop might never end.
It doesn't freeze when the mouse is outside the window because in this case no MouseMove event is generated and your event loop can finish.

But seriously, dude we need a better way to create a FPS camera or something.

I know. But right now there are other priorities.

[Groogy]

If you SetPosition and PollEvent in parallel, then the latter can be spammed by the former and your event loop might never end.

It happened while I had SetPosition commented out too.

Alright some more information. Tried a little with a breakpoint. I got a very weird behaviour.... While I was moving the mouse it seems that I never got out of the poll event loop. Because the breakpoint was only triggered when I stopped moving the mouse.

Code: [Select]

void GGE::Application::UpdateInput()
{
sf::Event event;
Threading::MessageList &list = mySynchro.GetOutput().GetList();
unsigned int numMoves = 0;
unsigned int numEvents = 0;
while( myWindow.PollEvent( event ) == true )
{
numEvents++;
if( event.Type == sf::Event::MouseMoved )
{
numMoves++;
continue;
}
InputMessage *message = new InputMessage( event, &myWindow );
list.AddElement( message );
}
if( numMoves > 10 )
{
numMoves = numMoves;   // <-- Breakpoint here
}
}
The result of numMoves was 90 and the result of numEvents was also 90. So the window got locked until the mouse stopped moving.

I want to point out the behaviour was not like this before the changes.

I am going to try and create a simple example to show.

[Groogy]

Actually I don't need to create a minimal example. The OpenGL example that come with SFML2 shows the same behaviour, both in debug and release.

NOTE: Actually it's the same for all SFML examples.

Filling out with some more information:
I'm on Windows 7 64 bit with the latest SFML2 compiled with VS10 32 bit.
My mouse input is a touch-pad or whatever it's called in English, the common thing that every laptop have to replace an actual mouse.

Also again, this worked perfectly before the new changes.

[Laurent]

Hmm... I'll so some tests :?

[Hiura]

pull events in one thread

I just wanted to point out that this thread _must_ be the main thread, at least on Mac OS X because of some (stupid) system limitations. I think this is not the case on Windows nor Linux so be aware of that while developing your engine stuff.

[Groogy]

I just wanted to point out that this thread _must_ be the main thread, at least on Mac OS X because of some (stupid) system limitations. I think this is not the case on Windows nor Linux so be aware of that while developing your engine stuff.

Already taken into account. Actually I think it is the same for them too but in Windows you can move it to another thread but it requires you to take some steps before you can do that. Don't remember exactly how, I stumbled upon it when tried to figure out why my Windows Message Loop didn't work for my school groups project, but it was such a mess so we just moved the message loop instead. Much easier!

[Laurent]

On Windows, event polling must happen in the thread that created the window.

[Groogy]

On Windows, event polling must happen in the thread that created the window.

Actually, if I remember correctly, you can give permission to other threads to pull events from the window. Something like that. But like I said, it was easier to just move the loop instead.

Anyway getting a bit off-topic.

[Laurent]

Actually, if I remember correctly, you can give permission to other threads to pull events from the window

Never heard about that. If you can find a source, let me know I'm interested

[Groogy]

Actually, if I remember correctly, you can give permission to other threads to pull events from the window

Never heard about that. If you can find a source, let me know I'm interested

It's like 3 months since I looked it up. I found it somewhere in the jungles of MSDN... I'll see if I can find it.