Whdn do events get queued?

If I move the mouse around, how many “MOUSEMOTION” events will get
queued? How does SDL determine that? I’m just curious about how it works
by the way.

A bunch :wink:

Usually it’s best to ignore all but the last mousemotion event. In other
words, dequeue them but don’t act on them until either another event occurs
or there are no other events in the queue, and then process the last one.

JeffOn Mon June 11 2007 18:16, Manuel Garc?a Cabrera wrote:

If I move the mouse around, how many “MOUSEMOTION” events will get
queued?

If I move the mouse around, how many “MOUSEMOTION” events will get
queued?

A bunch :wink:

Usually it’s best to ignore all but the last mousemotion event. In other
words, dequeue them but don’t act on them until either another event occurs
or there are no other events in the queue, and then process the last one.

Jeff

How many events can SDL queue, though, if you fail to pop them off the queue? Does it drop the oldest events if the queue fills up? Or does it just quit adding events until some events have been dequeued?>>> On 6/11/2007 at 9:10 PM, Jeff <j_post at pacbell.net> wrote:

On Mon June 11 2007 18:16, Manuel Garc?a Cabrera wrote:


Lilith

If I move the mouse around, how many “MOUSEMOTION” events will get
queued? How does SDL determine that? I’m just curious about how it works
by the way.

It depends on the underlying platform…SDL queues mouse motion events
as it gets them from the OS, and different ones work slightly
differently, but not in any significant way.

It won’t check with the OS until SDL_PumpEvents() is called in most
cases (which is called implicitly from SDL_PollEvent()).

–ryan.

How many events can SDL queue, though, if you fail to pop them off the queue?

…and while there’s a mechanism in SDL to decide if the queue
overflowed, nothing checks the return values, so you will silently
lose events if it overflows.

I’m a little horrified to learn this, having just checked, but it’s sort
of like checking malloc() for a return value…you can handle NULL,
but in 99% of the cases, your only option is to quit or crash anyhow.

Changing that to a dynamically growing linked list would solve the
issue, but honestly, I’m not sure it’s worth it. Realistically, it’s
never been a problem for me, though. Just handle events once per frame,
or look for this in SDL/src/events/SDL_events.c and make it bigger:

#define MAXEVENTS	128

–ryan.

Irrelevant. I did say dequeue them (pop them off the queue), but don’t act on
them until…

The queue won’t overflow if you remove the mousemotion events as they occur,
but processing them usually takes much more time than just popping them off
the queue. So only process the last mousemotion event, or every nth one, to
avoid slowing down your application or risking an event queue overflow.

JeffOn Mon June 11 2007 19:54, Lilith Calbridge wrote:

How many events can SDL queue, though, if you fail to pop them off the
queue?

Jeff wrote:> On Mon June 11 2007 19:54, Lilith Calbridge wrote:

How many events can SDL queue, though, if you fail to pop them off the
queue?

The queue won’t overflow if you remove the mousemotion events as they occur,
but processing them usually takes much more time than just popping them off
the queue. So only process the last mousemotion event, or every nth one, to
avoid slowing down your application or risking an event queue overflow.

Or as an alternative, you can just use SDL_GetMouseState() each time through the event loop. This seems much simpler to me, and I’ve never had a problem with it.

The queue won’t overflow if you remove the mousemotion events as they occur,
but processing them usually takes much more time than just popping them off
the queue. So only process the last mousemotion event, or every nth one, to
avoid slowing down your application or risking an event queue overflow.

You would really have to do a LOT of expensive processing, I’d imagine.

On Windows at least, you probably don’t get as many mouse motion events
as you think, either:

http://blogs.msdn.com/oldnewthing/archive/2003/10/01/55108.aspx

–ryan.