Author Topic: Polling events and setting cursor position thread safety (Read 5967 times)

Groogy · « **Reply #15 on:** July 08, 2011, 11:43:17 am »

Couldn't find it, must have misread/misremembered something... Though I'm pretty sure me and another group member came up with something but we decided that moving the loop was easier :?

Though just from looking at it for 15 min I could find it would be possible to forward all window messages to another threads message queue. (That was not what we came up with though)

NOTE: Not sure but it might have been something like this: http://msdn.microsoft.com/en-us/library/ms681956%28v=vs.85%29.aspx

Laurent · « **Reply #16 on:** July 08, 2011, 06:22:06 pm »

I can't reproduce the freezing thing. Have you tried to fully recompile everything?

Groogy · « **Reply #17 on:** July 08, 2011, 09:15:33 pm »

Quote from: "Laurent"

I can't reproduce the freezing thing. Have you tried to fully recompile everything?

Yepp I always do that and just did it again before posting just to be sure. Same result. I also tried putting in a mouse. Same result. The OpenGL is the most obvious one because of the rotating cube. While moving the mouse the cube stops moving and rotating until the mouse stops.

So just a theory. But feels like as the PollEvent function waits for the mouse to generate a mouse moved event before it returns while the mouse is moving.

Laurent · « **Reply #18 on:** July 08, 2011, 09:34:13 pm »

The logic inside Window::PollEvent is the same as before, even if the code slightly changed (mostly for WaitEvent).

It's weird that I can't reproduce it because I have the same environment as you (just using VC2008 instead of 2010).

Quote

Also again, this worked perfectly before the new changes.

Which revision exactly?

Groogy · « **Reply #19 on:** July 10, 2011, 06:01:21 pm »

Anyway regarding the problem we had with the locking while mouse being in motion... magically disappeared.... From examples.. from my engine...

So must have been my drivers or something.... Really freaky. Didn't recompile SFML2 or anything like that.

Just wanted you to know so that you can stop worrying about it Laurent ^^

Fray · « **Reply #20 on:** July 26, 2011, 10:17:36 pm »

Hi,

I am experiencing the exact same problem here and it looks like it comes from the Joystick event processing.
Commenting ProcessJoystickEvents(); from WindowImpl.cpp seems to "fix" the problem and also drastically improves the framerate.

Unfortunately I'm not knowledgeable enough to investigate the issue further.

SFML2 from github
VS 2010
SFML_STATIC
Win7 x86

OopsIDied · « **Reply #21 on:** August 11, 2011, 06:28:08 am »

Quote from: "Laurent"

Quote
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

I'm not sure what you guys are trying to do but it seems like this can be easily done with DLL Injection + subclassing the parent window's WndProc. Instead of passing the windows events to another thread, you move external code INTO the thread. You guys probably already knew about that but just making sure lol