MouseMove events + long taking poll loop = infinite loop |
MrTAToad
|
I would think a mouse event (like a keyboard one) would be created for every mouse movement or button pressed, although, of course, it may be interspersed with other messages.
Surely the removal of SDL_Delay would be the best thing to do ? |
|||||||||||
|
RudolfVonKrugstein
|
The SDL_Delay is only there to demonstrate the problem, I do not have any real code with it in it of course.
But what is a "complete" mouse movement? When I move the mouse over the complete screen in curved line, into how many segments (and mouse movement events) is it translated? |
|||||||||||||
|
mr_tawan
|
Separate the event handler into another thread might helps a little, but it would create the synchronization complexity .
There's another thing I can think of, which is just to poll the events in the loop, store in a queue, and then process them one by one outside of the event polling loop. Anyway if the processing an event takes 500ms (0.5 seconds) then there's some problem in that processing I believe. Especially when the event processing is inside the rendering loop, as it would hit the frame rate quite a lot. I think if the event processing takes an appropriate time then the infinite loop wouldn't occurs. |
|||||||||||
|
RodrigoCard
|
It is NOT a good idea to put a delay inside the event processing loop. Instead, let the loop run as fast as possible and put the delay after that. int running = 1; while (running) { while( SDL_PollEvent( &e ) != 0 ) { //print/handle event } SDL_Delay(500); } and the set running to 0 when you want it to break the outer loop. Also, I dont know why you want a 500ms delay, but I think you should look to do this instead: int running = 1; while (running) { while( SDL_WaitEvent( &e ) != 0 ) { //print/handle event } SDL_Delay(10); // or 1 or wherever } |
|||||||||||||
|
mr_tawan
|
@RodrigoCard I believe that the SDL_Delay() was placed there in place of some super-long event handling code.
|
|||||||||||
|
MrTAToad
|
I wonder if there is a problem with the posters processing code.
Whilst continual movement of a mouse will generate a mouse poll event, unless you have a machine to continually move a mouse thousands of times a second, there shouldn't be a problem. |
|||||||||||
|
RudolfVonKrugstein
|
Well, the problem is my processing code which takes too long, yes!
I fixed that, and it works now. So this becomes a theoretical question. Still - and I emphasize that this is a theoretical question - when I move my mouse in an arc, that arc is split into "MouseMove" events. How many of these events should I expect? Is there some rule how fine the arc is split up? |
|||||||||||
|
ANTA
|
No rule
It just repost MOUSEMOVE Window Msgs to you. |
|||||||||||
|
MouseMove events + long taking poll loop = infinite loop |
Jared Maddox
Guest
|
Have you tried checking the code? I suspect that the Operating System decides how many you get, in which case it's likely to be a user setting. If this ever becomes a genuine problem then it'll probably be an error on the part of either the user, the creator of the mouse, or you. Mice, being user-input devices, should have very long delays between their messages from the perspective of a computer. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|