MouseMove events + long taking poll loop = infinite loop

Hey,

I noticed that a loop like this:

Code:

while( SDL_PollEvent( &e ) != 0 ) {
//print/handle event
SDL_Delay(500);
}

cause the poll loop to never quit, because there are new mouse move events created before the last iteration of the loop is finished.
Ok, the leason is: do not take to much time in your poll loop. Makes sense.

But I wonder: how often are mouse move events created?

I actually have this problem in the SDL code of haxe/openfl (www.openfl.org) when the “HitTest” (testing if the mouse is above a button) takes to long on mouse move events.
What would your suggested way of handling this be?

Thanks!
Nathan

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 ?

The SDL_Delay is only there to demonstrate the problem, I do not have any real code with it in it of course.

I would think a mouse event (like a keyboard one) would be created for every mouse movement

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?

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.

mr_tawan wrote:

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.

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
}------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

@RodrigoCard I believe that the SDL_Delay() was placed there in place of some super-long event handling code.

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.

No rule
It just repost MOUSEMOVE Window Msgs to you.

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?

    loop

Message-ID: <1411986331.m2f.45460 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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?

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.> Date: Mon, 29 Sep 2014 10:25:31 +0000

From: “RudolfVonKrugstein” <nathan.huesken at posteo.de>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] MouseMove events + long taking poll loop = infinite