Hi,
I’m running into a case where libSDL drops events. It can be triggered with a low framerate (<5 fps) and lots of mouse motion. Looking at SDL_events.c, SDL_AddEvent() has a line that says ‘/* Overflow, drop event */’, and it appears that this is being executed. I can verify that the queue is actually full by checking how many events I can read in a while(SDL_PollEvent()) loop - events disappear when the number of events is close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting in a sane fashion, because they get multiple mouseups without mousedowns etc… So: Is there a good reason for MAXEVENTS being 128? Can we just make this a lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in question is unchanged in current trunk.–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: @Ulrich_von_Zadow
Skype: uzadow
5FPS is a rather low rate for polling events…
And yeah, increasing the value should work fine (albeit with more
memory usage, you’ll have to see how much is it), no idea if there’s
anything in the code hardcoded for it. The value there seems to have
been tuned for what’s the most common case.
Maybe in the future SDL2 could provide a function so the user can
define how much room to make for events? (leaving 128 as the default)
2013/6/10, Ulrich von Zadow :> Hi,
I’m running into a case where libSDL drops events. It can be triggered with
a low framerate (<5 fps) and lots of mouse motion. Looking at SDL_events.c,
SDL_AddEvent() has a line that says ‘/* Overflow, drop event */’, and it
appears that this is being executed. I can verify that the queue is actually
full by checking how many events I can read in a while(SDL_PollEvent()) loop
- events disappear when the number of events is close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting in
a sane fashion, because they get multiple mouseups without mousedowns etc…
So: Is there a good reason for MAXEVENTS being 128? Can we just make this a
lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in question
is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Yeah, the issue only appears in rather pathological cases, but then it turns a bad program into a crashing one. The cause of the crash can be pretty hard to diagnose :-/.
But this not about changing the private copy of libSDL I have here - it’s a proposal to make libSDL more stable in general by just changing MAXEVENTS to something like 1024. The library I’m maintaining (www.libavg.de) now outputs a warning if it detects a full libSDL event queue.
Cheers,
UliOn Jun 10, 2013, at 5:53 PM, Sik the hedgehog wrote:
5FPS is a rather low rate for polling events…
And yeah, increasing the value should work fine (albeit with more
memory usage, you’ll have to see how much is it), no idea if there’s
anything in the code hardcoded for it. The value there seems to have
been tuned for what’s the most common case.
Maybe in the future SDL2 could provide a function so the user can
define how much room to make for events? (leaving 128 as the default)
2013/6/10, Ulrich von Zadow <@Ulrich_von_Zadow>:
Hi,
I’m running into a case where libSDL drops events. It can be triggered with
a low framerate (<5 fps) and lots of mouse motion. Looking at SDL_events.c,
SDL_AddEvent() has a line that says ‘/* Overflow, drop event */’, and it
appears that this is being executed. I can verify that the queue is actually
full by checking how many events I can read in a while(SDL_PollEvent()) loop
- events disappear when the number of events is close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting in
a sane fashion, because they get multiple mouseups without mousedowns etc…
So: Is there a good reason for MAXEVENTS being 128? Can we just make this a
lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in question
is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: @Ulrich_von_Zadow
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: @Ulrich_von_Zadow
Skype: uzadow
Again, it may be better to propose SDL to implement a function to
increase the amount of events that can be queued instead, so the user
gets to decide how much is actually needed. Though remember any
changes will be only on SDL 2.0, consider 1.2 already dead.
If you want a better fix in the meanwhile, try to restructure the
program so it can poll events more often. 5 times per second is
already quite low and may even prompt the OS to behave in weird ways
if you’re unlucky. That should fix the event queue issue while also
helping make the program more responsive (to the OS at least).
2013/6/10, Ulrich von Zadow :> Yeah, the issue only appears in rather pathological cases, but then it turns
a bad program into a crashing one. The cause of the crash can be pretty hard
to diagnose :-/.
But this not about changing the private copy of libSDL I have here - it’s a
proposal to make libSDL more stable in general by just changing MAXEVENTS to
something like 1024. The library I’m maintaining (www.libavg.de) now outputs
a warning if it detects a full libSDL event queue.
Cheers,
Uli
On Jun 10, 2013, at 5:53 PM, Sik the hedgehog wrote:
5FPS is a rather low rate for polling events…
And yeah, increasing the value should work fine (albeit with more
memory usage, you’ll have to see how much is it), no idea if there’s
anything in the code hardcoded for it. The value there seems to have
been tuned for what’s the most common case.
Maybe in the future SDL2 could provide a function so the user can
define how much room to make for events? (leaving 128 as the default)
2013/6/10, Ulrich von Zadow :
Hi,
I’m running into a case where libSDL drops events. It can be triggered
with
a low framerate (<5 fps) and lots of mouse motion. Looking at
SDL_events.c,
SDL_AddEvent() has a line that says ‘/* Overflow, drop event */’, and it
appears that this is being executed. I can verify that the queue is
actually
full by checking how many events I can read in a while(SDL_PollEvent())
loop
- events disappear when the number of events is close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting
in
a sane fashion, because they get multiple mouseups without mousedowns
etc…
So: Is there a good reason for MAXEVENTS being 128? Can we just make this
a
lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in
question
is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
There’s no reason why this can’t be a dynamic list these days. I’ll look
into making that change. In the meantime, you can bump the number up to
whatever makes sense for you.
Cheers!On Mon, Jun 10, 2013 at 8:38 AM, Ulrich von Zadow wrote:
Hi,
I’m running into a case where libSDL drops events. It can be triggered
with a low framerate (<5 fps) and lots of mouse motion. Looking at
SDL_events.c, SDL_AddEvent() has a line that says ‘/* Overflow, drop event
*/’, and it appears that this is being executed. I can verify that the
queue is actually full by checking how many events I can read in a
while(SDL_PollEvent()) loop - events disappear when the number of events is
close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting
in a sane fashion, because they get multiple mouseups without mousedowns
etc… So: Is there a good reason for MAXEVENTS being 128? Can we just make
this a lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in question
is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Le Mon, 10 Jun 2013 09:23:53 -0700
Sam Lantinga a ?crit:
There’s no reason why this can’t be a dynamic list these days. I’ll look
into making that change. In the meantime, you can bump the number up to
whatever makes sense for you.
I encountered a similar problem once with XBMC, and wrote a patch to
merge consecutive mouse motion events, as long as mouse button status
does not change:
http://bugzilla.libsdl.org/show_bug.cgi?id=1089--
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux
“who writes the code, decides”
Le Mon, 10 Jun 2013 09:23:53 -0700
Sam Lantinga a ?crit:
There’s no reason why this can’t be a dynamic list these days. I’ll look
into making that change. In the meantime, you can bump the number up to
whatever makes sense for you.
That would of course be the most elegant solution, thanks!
I encountered a similar problem once with XBMC, and wrote a patch to
merge consecutive mouse motion events, as long as mouse button status
does not change:
http://bugzilla.libsdl.org/show_bug.cgi?id=1089
I can second that this would be a very nice feature to have, because it has the potential to save a lot of processing time on the application side. It also means that the current queue size would be big enough for all but completely pathological cases.
In fact, libavg already merges mouse motion events right after receiving them from libSDL. Mac OS X merges them before they get to the application, Linux/X11 doesn’t.
Cheers,
UliOn Jun 10, 2013, at 8:47 PM, Patrice Mandin wrote:
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: @Ulrich_von_Zadow
Skype: uzadow
Okay, the latest snapshot has this change:
Please let me know if you find any bugs or performance problems!
Thanks!On Mon, Jun 10, 2013 at 9:23 AM, Sam Lantinga <@slouken> wrote:
There’s no reason why this can’t be a dynamic list these days. I’ll look
into making that change. In the meantime, you can bump the number up to
whatever makes sense for you.
Cheers!
On Mon, Jun 10, 2013 at 8:38 AM, Ulrich von Zadow wrote:
Hi,
I’m running into a case where libSDL drops events. It can be triggered
with a low framerate (<5 fps) and lots of mouse motion. Looking at
SDL_events.c, SDL_AddEvent() has a line that says ‘/* Overflow, drop event
*/’, and it appears that this is being executed. I can verify that the
queue is actually full by checking how many events I can read in a
while(SDL_PollEvent()) loop - events disappear when the number of events is
close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting
in a sane fashion, because they get multiple mouseups without mousedowns
etc… So: Is there a good reason for MAXEVENTS being 128? Can we just make
this a lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in
question is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
The dynamic implementation is great, but a limitless queue of events do
not make much sense either. I think there are cases where we DO want to
drop events.
What if the queue grows to 100K due to a programming mistake or some
other external reason? “Limitless” is never a safe, and your new limit
it the hardware resource. I would recommend to reinstate some limits
again - could be a high one, like 32K - and add a simple API to adjust
it like SDL_SetEventQueueLimit(int size). The dynamic implementation
guarantees that for most cases we never get there, but if we do, an
event queue limit would prevent any resources depletion and protect an
event processing loop from “hanging” the application. And one can always
overload the meaning of size to disable the limit (if <1, current
limitless behavior) should this be a desired behavior.
My 2 cents.On 6/10/2013 11:31 PM, Sam Lantinga wrote:
Okay, the latest snapshot has this change:
http://hg.libsdl.org/SDL/rev/9598cbf46957
Please let me know if you find any bugs or performance problems!
Thanks!
On Mon, Jun 10, 2013 at 9:23 AM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
There's no reason why this can't be a dynamic list these days.
I'll look into making that change. In the meantime, you can bump
the number up to whatever makes sense for you.
Cheers!
On Mon, Jun 10, 2013 at 8:38 AM, Ulrich von Zadow <coder at c-base.org <mailto:coder at c-base.org>> wrote:
Hi,
I'm running into a case where libSDL drops events. It can be
triggered with a low framerate (<5 fps) and lots of mouse
motion. Looking at SDL_events.c, SDL_AddEvent() has a line
that says '/* Overflow, drop event */', and it appears that
this is being executed. I can verify that the queue is
actually full by checking how many events I can read in a
while(SDL_PollEvent()) loop - events disappear when the number
of events is close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way
of reacting in a sane fashion, because they get multiple
mouseups without mousedowns etc.. So: Is there a good reason
for MAXEVENTS being 128? Can we just make this a lot bigger?
Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code
in question is unchanged in current trunk.
--
Any technology distinguishable from magic is insufficiently
advanced.
Ulrich von Zadow | +49-172-7872715 <tel:%2B49-172-7872715>
Jabber: coder at c-base.org <mailto:coder at c-base.org>
Skype: uzadow
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Okay, I threw a 64k limit in there. We can add a dynamic limit later if it
becomes an issue.On Tue, Jun 11, 2013 at 7:39 AM, Andreas Schiffler wrote:
The dynamic implementation is great, but a limitless queue of events do
not make much sense either. I think there are cases where we DO want to
drop events.
What if the queue grows to 100K due to a programming mistake or some other
external reason? “Limitless” is never a safe, and your new limit it the
hardware resource. I would recommend to reinstate some limits again - could
be a high one, like 32K - and add a simple API to adjust it like
SDL_SetEventQueueLimit(int size). The dynamic implementation guarantees
that for most cases we never get there, but if we do, an event queue limit
would prevent any resources depletion and protect an event processing loop
from “hanging” the application. And one can always overload the meaning of
size to disable the limit (if <1, current limitless behavior) should this
be a desired behavior.
My 2 cents.
On 6/10/2013 11:31 PM, Sam Lantinga wrote:
Okay, the latest snapshot has this change:
http://hg.libsdl.org/SDL/rev/9598cbf46957
Please let me know if you find any bugs or performance problems!
Thanks!
On Mon, Jun 10, 2013 at 9:23 AM, Sam Lantinga <@slouken> wrote:
There’s no reason why this can’t be a dynamic list these days. I’ll look
into making that change. In the meantime, you can bump the number up to
whatever makes sense for you.
Cheers!
On Mon, Jun 10, 2013 at 8:38 AM, Ulrich von Zadow wrote:
Hi,
I’m running into a case where libSDL drops events. It can be triggered
with a low framerate (<5 fps) and lots of mouse motion. Looking at
SDL_events.c, SDL_AddEvent() has a line that says ‘/* Overflow, drop event
*/’, and it appears that this is being executed. I can verify that the
queue is actually full by checking how many events I can read in a
while(SDL_PollEvent()) loop - events disappear when the number of events is
close to 128.
Am I understanding this correctly?
If events are dropped, user programs have essentially no way of reacting
in a sane fashion, because they get multiple mouseups without mousedowns
etc… So: Is there a good reason for MAXEVENTS being 128? Can we just make
this a lot bigger? Or is there a better way of handling this issue?
Regards,
Uli
PS: Tested with libSDL 1.2.15 under Ubuntu 13.04, but the code in
question is unchanged in current trunk.
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Okay, I threw a 64k limit in there. We can add a dynamic limit later
if it becomes an issue.
How about the mouse movement merging bug (and now out of date patch)
referenced by Ulrich? Probably an even more valid issue with the
enlarged queue size.On Tue, 2013-06-11 at 08:38 -0700, Sam Lantinga wrote:
On Tue, Jun 11, 2013 at 7:39 AM, Andreas Schiffler wrote:
The dynamic implementation is great, but a limitless queue of
events do not make much sense either. I think there are cases
where we DO want to drop events.
What if the queue grows to 100K due to a programming mistake
or some other external reason? "Limitless" is never a safe,
and your new limit it the hardware resource. I would recommend
to reinstate some limits again - could be a high one, like 32K
- and add a simple API to adjust it like
SDL_SetEventQueueLimit(int size). The dynamic implementation
guarantees that for most cases we never get there, but if we
do, an event queue limit would prevent any resources depletion
and protect an event processing loop from "hanging" the
application. And one can always overload the meaning of size
to disable the limit (if <1, current limitless behavior)
should this be a desired behavior.
My 2 cents.
On 6/10/2013 11:31 PM, Sam Lantinga wrote:
> Okay, the latest snapshot has this change:
> http://hg.libsdl.org/SDL/rev/9598cbf46957
> Please let me know if you find any bugs or performance
> problems!
I wouldn’t want mouse merging by default. The extra precision is really
useful for things like Tux Paint.
I’m fine with a patch that enables it via a hint though.
Cheers!On Fri, Jun 14, 2013 at 3:32 AM, Alan Swanson wrote:
On Tue, 2013-06-11 at 08:38 -0700, Sam Lantinga wrote:
Okay, I threw a 64k limit in there. We can add a dynamic limit later
if it becomes an issue.
How about the mouse movement merging bug (and now out of date patch)
referenced by Ulrich? Probably an even more valid issue with the
enlarged queue size.
On Tue, Jun 11, 2013 at 7:39 AM, Andreas Schiffler wrote:
The dynamic implementation is great, but a limitless queue of
events do not make much sense either. I think there are cases
where we DO want to drop events.
What if the queue grows to 100K due to a programming mistake
or some other external reason? "Limitless" is never a safe,
and your new limit it the hardware resource. I would recommend
to reinstate some limits again - could be a high one, like 32K
- and add a simple API to adjust it like
SDL_SetEventQueueLimit(int size). The dynamic implementation
guarantees that for most cases we never get there, but if we
do, an event queue limit would prevent any resources depletion
and protect an event processing loop from "hanging" the
application. And one can always overload the meaning of size
to disable the limit (if <1, current limitless behavior)
should this be a desired behavior.
My 2 cents.
On 6/10/2013 11:31 PM, Sam Lantinga wrote:
> Okay, the latest snapshot has this change:
> http://hg.libsdl.org/SDL/rev/9598cbf46957
> Please let me know if you find any bugs or performance
> problems!
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org