[SDL] Re: Question about ignoring mouse events

David Olofson david at olofson.net
Wed Nov 16 12:19:32 PST 2005


On Wednesday 16 November 2005 19.10, Román Gorojovsky wrote:
[...]
> ok, but is there an important difference between the following?

Well, if you insert (unconditional) rendering code...

>   while (1)
>   {
>       if (SDL_PollEvent(&event))
>       {
>             /* process events */
>             case SDL_QUIT:
>                    exit(0);
>       }

...here...

>   }
> 
> vs
> 
>   while (1)
>   {
>       while (SDL_PollEvent(&event))
>       {
>             /* process events */
>       }

...and here...

>   }


...there is a big difference in the chances of keeping up with the 
input event stream. The first version will helplessly lag behind and 
add an increasing delay, if it cannot render fast enough to generate 
one frame per input event.

However, if you make sure not to repaint the screen, or get stuck 
waiting for the retrace (ie SDL_Flip()) every loop, you may still be 
fine.


> Should I handle the SDL_QUIT case differently?

Doesn't really matter; it's just another event, basically. In fact, 
you can chose to ignore it, pop up a "Sure?" dialog or something and 
keep running if the user cancels the operation. SDL_QUIT just means 
the user klicked the X button, or whatever one does on the OS we're 
on.


> > Note that the latter (emptying the event queue before you move on)
> > is very important! If you don't do it that way, you'll get this
> > horrible "rubber band" delay effect as soon as your rendering loop
> > cannot spin at least once per input event. (Which it most likely
> > cannot, unless the user has a low frame rate mouse and/or you're
> > doing OpenGL rendering without retrace sync.)
> >
> humm I'm not sure if I'm following you.  I don't have a rendering
> loop.  I render, then I check events, and then if I have to render
> again I do it. 

Well, that sounds pretty much like an event driven application then 
(as in, it's not spinning full speed rendering frames at all times) - 
but this alone does not mean you completely avoid the problem! All it 
takes is responding to mouse moves or other events that may arrive at 
high frequencies and you may fall in the "one event per frame" trap.


> The rendering loop only checks the SDL_QUIT event. 

That is, rendering may take long enough that there is reason to check 
SDL_QUIT while doing it...? That makes it even more important to 
process all pending events whenever you have a chance to handle them 
properly.

If it takes more than a second or so to render a frame, you should 
probably decouple the rest of the visual feedback from this 
rendering, so the application doesn't appear to be completely frozen 
while rendering.

The best way to deal with this sort of stuff is usually to do the 
rendering completely asynchronously in the background, with automatic 
abort/restart if the user changes parameters while rendering. Serious 
image processing applications have to do this to be realistically 
usable on very large images, and IMHO, something like this should be 
done whenever possible, as soon as delays in interactive work start 
crossing this magic one second stress limit.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---




More information about the SDL mailing list