Some multithreaded improvement to the event queue

SDL Development
1

Hello all.

I did a small improvement run on SDL_events.c to stratch an itch of mine that
results in the following features:

  • SDL_WaitEvent() is now properly blocks the calling thread when there are no
    pending events (and wakes it up immediately when events arrive rather than
    miss them by up to 10ms because of the SDL_Delay)

  • If the event queue gets full, the thread that is adding the events will be
    blocked until room becomes available rather than just drop them on the floor.

Both features are only enabled when SDL_INIT_EVENTTHREAD is given to
SDL_Init() and the event thread was created successfuly. They don’t make
sense if you don’t have a separate event collection thread anyways.

I’ve only tested this under Linux, but I use no machine dependent code so
it /should/ work on any platform where threads work correctly.

The included diff was made against 1.2.9.

– Marc A. Pelletier

— orig/src/events/SDL_events.c 2005-09-13 00:26:16.000000000 -0400
+++ new/src/events/SDL_events.c 2005-09-13 08:34:23.000000000 -0400
@@ -68,6 +68,16 @@
int safe;
} SDL_EventLock;

+static struct {

  • SDL_mutex* lock;
  • SDL_cond* cond;
    +} SDL_Empty_EventCond;+
    +static struct {
  • SDL_mutex* lock;
  • SDL_cond* cond;
    +} SDL_Full_EventCond;

/* Thread functions */
static SDL_Thread SDL_EventThread = NULL; / Thread handle /
static Uint32 event_thread; / The event thread id */
@@ -156,7 +166,13 @@

if ( (flags&SDL_INIT_EVENTTHREAD) == SDL_INIT_EVENTTHREAD ) {
SDL_EventLock.lock = SDL_CreateMutex();

  • if ( SDL_EventLock.lock == NULL ) {
  • SDL_Empty_EventCond.lock = SDL_CreateMutex();
  • SDL_Empty_EventCond.cond = SDL_CreateCond();
  • SDL_Full_EventCond.lock = SDL_CreateMutex();
  • SDL_Full_EventCond.cond = SDL_CreateCond();
  • if (SDL_EventLock.lock== NULL
  • || SDL_Empty_EventCond.lock==NULL || SDL_Empty_EventCond.cond==NULL
  • || SDL_Full_EventCond.lock==NULL || SDL_Full_EventCond.cond==NULL) {
    return(-1);
    }
    SDL_EventLock.safe = 0;
    @@ -249,31 +265,39 @@
    /* Add an event to the event queue – called with the queue locked */
    static int SDL_AddEvent(SDL_Event *event)
    {
  • int tail, added;
  • int tail;
  • tail = (SDL_EventQ.tail+1)%MAXEVENTS;
  • if ( tail == SDL_EventQ.head ) {
  • /* Overflow, drop event */
  • added = 0;
  • } else {
  • SDL_EventQ.event[SDL_EventQ.tail] = *event;
  • if (event->type == SDL_SYSWMEVENT) {
  • /* Note that it’s possible to lose an event */
  • int next = SDL_EventQ.wmmsg_next;
  • SDL_EventQ.wmmsg[next] = *event->syswm.msg;
  •      SDL_EventQ.event[SDL_EventQ.tail].syswm.msg =

  •  &SDL_EventQ.wmmsg[next];
  • SDL_EventQ.wmmsg_next = (next+1)%MAXEVENTS;
  • }
  • SDL_EventQ.tail = tail;
  • added = 1;
  • if ( SDL_EventThread )
  • SDL_mutexP(SDL_Full_EventCond.lock);
  • while ( (tail = (SDL_EventQ.tail+1)%MAXEVENTS) == SDL_EventQ.head ) {
  • if ( !SDL_EventThread )
  • return 0;
  • SDL_CondWait(SDL_Full_EventCond.cond, SDL_Full_EventCond.lock);
  • }
  • SDL_EventQ.event[SDL_EventQ.tail] = *event;
  • if (event->type == SDL_SYSWMEVENT) {
  • /* Note that it’s possible to lose an event */
  • int next = SDL_EventQ.wmmsg_next;
  • SDL_EventQ.wmmsg[next] = *event->syswm.msg;
  •     SDL_EventQ.event[SDL_EventQ.tail].syswm.msg =

  • &SDL_EventQ.wmmsg[next];
  • SDL_EventQ.wmmsg_next = (next+1)%MAXEVENTS;
    }
  • return(added);
  • SDL_EventQ.tail = tail;
  • if ( SDL_EventThread ) {
  • SDL_CondSignal(SDL_Empty_EventCond.cond);
  • SDL_mutexV(SDL_Full_EventCond.lock);
  • }
  • return 1;
    }

/* Cut an event, and return the next valid spot, or the tail /
/ – called with the queue locked /
-static int SDL_CutEvent(int spot)
+static int SDL_CutEvent_internal(int spot)
{
if ( spot == SDL_EventQ.head ) {
SDL_EventQ.head = (SDL_EventQ.head+1)%MAXEVENTS;
@@ -300,6 +324,19 @@
/ NOTREACHED */
}

+static int SDL_CutEvent(int spot)
+{

  • int retval;
  • if ( !SDL_EventThread )
  • return SDL_CutEvent_internal(spot);
  • SDL_mutexP(SDL_Full_EventCond.lock);
  • retval = SDL_CutEvent_internal(spot);
  • SDL_CondSignal(SDL_Full_EventCond.cond);
  • SDL_mutexV(SDL_Full_EventCond.lock);
    +}

/* Lock the event queue, take a peep at it, and unlock it */
int SDL_PeepEvents(SDL_Event *events, int numevents, SDL_eventaction action,
Uint32 mask)
@@ -387,12 +424,24 @@

int SDL_WaitEvent (SDL_Event *event)
{

  • if ( SDL_EventThread )
  • SDL_mutexP(SDL_Empty_EventCond.lock);
    while ( 1 ) {
    SDL_PumpEvents();
    switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
  •  case -1: return 0;

  •  case 1: return 1;

  •  case 0: SDL_Delay(10);

  •  case -1:
  • if ( SDL_EventThread )
  • SDL_mutexV(SDL_Empty_EventCond.lock);
  • return 0;
  •  case 1:
  • if ( SDL_EventThread )
  • SDL_mutexV(SDL_Empty_EventCond.lock);
  • return 1;
  •  case 0:
  • if ( SDL_EventThread )
  • SDL_CondWait(SDL_Empty_EventCond.cond, SDL_Empty_EventCond.lock);
  • else
  • SDL_Delay(10);
    }
    }
    }
2

Hello all.

I did a small improvement run on SDL_events.c to stratch an itch of mine that
results in the following features:

Good luck. I released a replacement library that does just what you did
http://gameprogrammer.com/fastevents/fastevents1.html I did it that way
because I could not get agreement to put code like yours into SDL. It
wasn’t accepted because SDL runs on operating systems that do not
support threads.

You can read some of my commentary on this at
http://www.libsdl.org/pipermail/sdl/2002-June/046132.html

	Bob PendletonOn Tue, 2005-09-13 at 10:19 -0400, Marc A. Pelletier wrote:

  • SDL_WaitEvent() is now properly blocks the calling thread when there are no
    pending events (and wakes it up immediately when events arrive rather than
    miss them by up to 10ms because of the SDL_Delay)

  • If the event queue gets full, the thread that is adding the events will be
    blocked until room becomes available rather than just drop them on the floor.

Both features are only enabled when SDL_INIT_EVENTTHREAD is given to
SDL_Init() and the event thread was created successfuly. They don’t make
sense if you don’t have a separate event collection thread anyways.

I’ve only tested this under Linux, but I use no machine dependent code so
it /should/ work on any platform where threads work correctly.

The included diff was made against 1.2.9.

– Marc A. Pelletier

— orig/src/events/SDL_events.c 2005-09-13 00:26:16.000000000 -0400
+++ new/src/events/SDL_events.c 2005-09-13 08:34:23.000000000 -0400
@@ -68,6 +68,16 @@
int safe;
} SDL_EventLock;

+static struct {

  • SDL_mutex* lock;
  • SDL_cond* cond;
    +} SDL_Empty_EventCond;

+static struct {

  • SDL_mutex* lock;
  • SDL_cond* cond;
    +} SDL_Full_EventCond;

/* Thread functions */
static SDL_Thread SDL_EventThread = NULL; / Thread handle /
static Uint32 event_thread; / The event thread id */
@@ -156,7 +166,13 @@

if ( (flags&SDL_INIT_EVENTTHREAD) == SDL_INIT_EVENTTHREAD ) {
SDL_EventLock.lock = SDL_CreateMutex();

  • if ( SDL_EventLock.lock == NULL ) {
  • SDL_Empty_EventCond.lock = SDL_CreateMutex();
  • SDL_Empty_EventCond.cond = SDL_CreateCond();
  • SDL_Full_EventCond.lock = SDL_CreateMutex();
  • SDL_Full_EventCond.cond = SDL_CreateCond();
  • if (SDL_EventLock.lock== NULL
  • || SDL_Empty_EventCond.lock==NULL || SDL_Empty_EventCond.cond==NULL
  • || SDL_Full_EventCond.lock==NULL || SDL_Full_EventCond.cond==NULL) {
    return(-1);
    }
    SDL_EventLock.safe = 0;
    @@ -249,31 +265,39 @@
    /* Add an event to the event queue – called with the queue locked */
    static int SDL_AddEvent(SDL_Event *event)
    {
  • int tail, added;
  • int tail;
  • tail = (SDL_EventQ.tail+1)%MAXEVENTS;
  • if ( tail == SDL_EventQ.head ) {
  • /* Overflow, drop event */
  • added = 0;
  • } else {
  • SDL_EventQ.event[SDL_EventQ.tail] = *event;
  • if (event->type == SDL_SYSWMEVENT) {
  • /* Note that it’s possible to lose an event */
  • int next = SDL_EventQ.wmmsg_next;
  • SDL_EventQ.wmmsg[next] = *event->syswm.msg;
  •      SDL_EventQ.event[SDL_EventQ.tail].syswm.msg =

  •  &SDL_EventQ.wmmsg[next];
  • SDL_EventQ.wmmsg_next = (next+1)%MAXEVENTS;
  • }
  • SDL_EventQ.tail = tail;
  • added = 1;
  • if ( SDL_EventThread )
  • SDL_mutexP(SDL_Full_EventCond.lock);
  • while ( (tail = (SDL_EventQ.tail+1)%MAXEVENTS) == SDL_EventQ.head ) {
  • if ( !SDL_EventThread )
  • return 0;
  • SDL_CondWait(SDL_Full_EventCond.cond, SDL_Full_EventCond.lock);
  • }
  • SDL_EventQ.event[SDL_EventQ.tail] = *event;
  • if (event->type == SDL_SYSWMEVENT) {
  • /* Note that it’s possible to lose an event */
  • int next = SDL_EventQ.wmmsg_next;
  • SDL_EventQ.wmmsg[next] = *event->syswm.msg;
  •     SDL_EventQ.event[SDL_EventQ.tail].syswm.msg =

  • &SDL_EventQ.wmmsg[next];
  • SDL_EventQ.wmmsg_next = (next+1)%MAXEVENTS;
    }
  • return(added);
  • SDL_EventQ.tail = tail;
  • if ( SDL_EventThread ) {
  • SDL_CondSignal(SDL_Empty_EventCond.cond);
  • SDL_mutexV(SDL_Full_EventCond.lock);
  • }
  • return 1;
    }

/* Cut an event, and return the next valid spot, or the tail /
/ – called with the queue locked /
-static int SDL_CutEvent(int spot)
+static int SDL_CutEvent_internal(int spot)
{
if ( spot == SDL_EventQ.head ) {
SDL_EventQ.head = (SDL_EventQ.head+1)%MAXEVENTS;
@@ -300,6 +324,19 @@
/ NOTREACHED */
}

+static int SDL_CutEvent(int spot)
+{

  • int retval;
  • if ( !SDL_EventThread )
  • return SDL_CutEvent_internal(spot);
  • SDL_mutexP(SDL_Full_EventCond.lock);
  • retval = SDL_CutEvent_internal(spot);
  • SDL_CondSignal(SDL_Full_EventCond.cond);
  • SDL_mutexV(SDL_Full_EventCond.lock);
    +}

/* Lock the event queue, take a peep at it, and unlock it */
int SDL_PeepEvents(SDL_Event *events, int numevents, SDL_eventaction action,
Uint32 mask)
@@ -387,12 +424,24 @@

int SDL_WaitEvent (SDL_Event *event)
{

  • if ( SDL_EventThread )
  • SDL_mutexP(SDL_Empty_EventCond.lock);
    while ( 1 ) {
    SDL_PumpEvents();
    switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
  •  case -1: return 0;

  •  case 1: return 1;

  •  case 0: SDL_Delay(10);

  •  case -1:
  • if ( SDL_EventThread )
  • SDL_mutexV(SDL_Empty_EventCond.lock);
  • return 0;
  •  case 1:
  • if ( SDL_EventThread )
  • SDL_mutexV(SDL_Empty_EventCond.lock);
  • return 1;
  •  case 0:
  • if ( SDL_EventThread )
  • SDL_CondWait(SDL_Empty_EventCond.cond, SDL_Empty_EventCond.lock);
  • else
  • SDL_Delay(10);
    }
    }
    }

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

–
±-------------------------------------+

3

Bob Pendleton wrote:

Good luck. I released a replacement library that does just what you did
http://gameprogrammer.com/fastevents/fastevents1.html I did it that way
because I could not get agreement to put code like yours into SDL. It
wasn’t accepted because SDL runs on operating systems that do not
support threads.

This may not be such a problem; my patch does nothing unless you
specifically request SDL_INIT_EVENTTHREAD (and get it) so OSes that do not
support thread will not be affected.

And, indeed, on platforms which /do/ support threads, the actual semantics
are left unchanged: SDL_WaitEvent() will return faster once an event is
available and not hog (part of) the CPU while it waits, but will otherwise
act exactly as it always had.

The only other change (not dropping events when the queue is full) is
arguably a bugfix. I wouldn’t expect any library user is legitimately
relying on events being lost. :slight_smile: (And, a fixed queue length is somewhat
less an issue on platforms which do not support threads given that events
will be added to the queue only when the program is actively reading those
events-- you can’t loose events simply because you happened to be busy
doing something else).

– Marc A. Pelletier

4

El mar, 13-09-2005 a las 18:41, Marc A. Pelletier escribi?:

Bob Pendleton wrote:

Good luck. I released a replacement library that does just what you did
http://gameprogrammer.com/fastevents/fastevents1.html I did it that way
because I could not get agreement to put code like yours into SDL. It
wasn’t accepted because SDL runs on operating systems that do not
support threads.

This may not be such a problem; my patch does nothing unless you
specifically request SDL_INIT_EVENTTHREAD (and get it) so OSes that do not
support thread will not be affected.
What OSes doesnt support threads?–
Roger D. Vargas
Linux user #180787
dsgp.blogspot.com

  • No hay nada tan importante que no pueda ser olvidado *
    Alzheimer
5

Most embedded systems come to mind.

  • SROn 9/13/05, Roger D. Vargas wrote:

What OSes doesnt support threads?

6

And, indeed, on platforms which /do/ support threads, the
actual semantics
are left unchanged: SDL_WaitEvent() will return faster once
an event is
available and not hog (part of) the CPU while it waits, but
will otherwise
act exactly as it always had.

this is a change that i, for one, (for what its worth) would like to
see in SDL. is there somewhere other than this list that one can
watch to determine which patches have been accepted?

The only other change (not dropping events when the queue is full) is
arguably a bugfix. I wouldn’t expect any library user is legitimately
relying on events being lost. :slight_smile:

and argue i shall :wink: well, perhaps not argue so much as clear my own
misunderstandings of how SDL works…

while i agree that no user should be relying on events being lost when
the queue is full, i think its a good way to handle a bad situation.
it is, to me, the least error-prone way of handling such a situation.

are there not consequences to blocking the event delivery thread?
won’t this result in the application appearing unresponsive to the OS?

assuming SDL handles certain events before putting them on the queue
(like redrawing when focus is gained), the application may continue to
appear to be OK and be given a chance to recover. if the queue filled
up because of a temporary processing blip, then this may be desirable.

just thinking out loud…
.marc

7

Marc Daya wrote:

The only other change (not dropping events when the queue is full)
[…]
relying on events being lost. :slight_smile:

and argue i shall :wink: well, perhaps not argue so much as clear my own
misunderstandings of how SDL works…

while i agree that no user should be relying on events being lost when
the queue is full, i think its a good way to handle a bad situation.
it is, to me, the least error-prone way of handling such a situation.

It might have been, perhaps, given a bit of smartness: you might want to
cumulate mouse movement, perhaps, or drop event /pairs/ which cancel each
other. But you really wouldn’t want to drop, say, a key release event if
you kept the key press. (key repeat anyone?) But the decision on what
events are “worth” keeping is best left to application logic-- a painting
program might really want to keep all mouse motion but not care so much
about the keyboard, etc.

are there not consequences to blocking the event delivery thread?
won’t this result in the application appearing unresponsive to the OS?

It cannot be any worse than just not asking for the EVENTTHREAD at
SDL_Init(): events are just polled everytime you SDL_WaitEvent() or
SDL_PollEvent(). If your code is busy doing something else, it’s not
polling at all (rather than being able to snarf as many events as would
fill the queue before it has to stop).

The net effect is that your application would appear more responsive to
the OS.

Incidentally, I’m no Win32 expert, but my impression was that the
determination that an application “has stopped responding” was only done
upon specific user action (trying to close the app, etc) and that there was
a sizable delay in making that determination. Arguably, (yes, feel free to
argue again) :slight_smile: a program which has completely stopped draining events
from the queue for several seconds and that the user is actively trying to
kill is no longer responding.

– Marc A. Pelletier

8

Question… (without looking at the code) why is it that the size of the
event queue a compile time option?

Marc Daya wrote:>>And, indeed, on platforms which /do/ support threads, the

actual semantics
are left unchanged: SDL_WaitEvent() will return faster once
an event is
available and not hog (part of) the CPU while it waits, but
will otherwise
act exactly as it always had.

this is a change that i, for one, (for what its worth) would like to
see in SDL. is there somewhere other than this list that one can
watch to determine which patches have been accepted?

The only other change (not dropping events when the queue is full) is
arguably a bugfix. I wouldn’t expect any library user is legitimately
relying on events being lost. :slight_smile:

and argue i shall :wink: well, perhaps not argue so much as clear my own
misunderstandings of how SDL works…

while i agree that no user should be relying on events being lost when
the queue is full, i think its a good way to handle a bad situation.
it is, to me, the least error-prone way of handling such a situation.

are there not consequences to blocking the event delivery thread?
won’t this result in the application appearing unresponsive to the OS?

assuming SDL handles certain events before putting them on the queue
(like redrawing when focus is gained), the application may continue to
appear to be OK and be given a chance to recover. if the queue filled
up because of a temporary processing blip, then this may be desirable.

just thinking out loud…
.marc

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

9

Antonio SJ Musumeci wrote:

Question… (without looking at the code) why is it that the size of the
event queue a compile time option?

Strictly speaking, it’s not.

There is a define with the size of the queue in SDL_events.c, and I expect
it could be changed to any power-of-two, but it’s not a compile-time
tunable. You have to change the source itself.

– Marc A. Pelletier

10

That’s what I meant. The size is set at compile time… not runtime. But
why?

Marc A. Pelletier wrote:> Antonio SJ Musumeci wrote:

Question… (without looking at the code) why is it that the size of the
event queue a compile time option?

Strictly speaking, it’s not.

There is a define with the size of the queue in SDL_events.c, and I expect
it could be changed to any power-of-two, but it’s not a compile-time
tunable. You have to change the source itself.

– Marc A. Pelletier

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

11

El mar, 13-09-2005 a las 18:41, Marc A. Pelletier escribi?:

Bob Pendleton wrote:

Good luck. I released a replacement library that does just what you did
http://gameprogrammer.com/fastevents/fastevents1.html I did it that way
because I could not get agreement to put code like yours into SDL. It
wasn’t accepted because SDL runs on operating systems that do not
support threads.

This may not be such a problem; my patch does nothing unless you
specifically request SDL_INIT_EVENTTHREAD (and get it) so OSes that do not
support thread will not be affected.
What OSes doesnt support threads?

Well, the only one I can thin of is Mac OS classic. But, there are bound
to be others.

	Bob PendletonOn Tue, 2005-09-13 at 16:07 +0000, Roger D. Vargas wrote:

–
±-------------------------------------+

12

Bob Pendleton wrote:

Good luck. I released a replacement library that does just what you did
http://gameprogrammer.com/fastevents/fastevents1.html I did it that way
because I could not get agreement to put code like yours into SDL. It
wasn’t accepted because SDL runs on operating systems that do not
support threads.

This may not be such a problem; my patch does nothing unless you
specifically request SDL_INIT_EVENTTHREAD (and get it) so OSes that do not
support thread will not be affected.

In other words your patch won’t work on Windows? SDL_INIT_EVENTTHREAD is
used to run the event handler in a separate thread. Windows does not
allow that, so even though windows supports threads your patch won’t
work there. This correction can be made to work on Windows (FastEvents
works just fine on Windows) even though SDL_TINIT_EVENTTHREAD can not be
used on Windows.

And, indeed, on platforms which /do/ support threads, the actual semantics
are left unchanged: SDL_WaitEvent() will return faster once an event is
available and not hog (part of) the CPU while it waits, but will otherwise
act exactly as it always had.

The only other change (not dropping events when the queue is full) is
arguably a bugfix. I wouldn’t expect any library user is legitimately
relying on events being lost. :slight_smile: (And, a fixed queue length is somewhat
less an issue on platforms which do not support threads given that events
will be added to the queue only when the program is actively reading those
events-- you can’t loose events simply because you happened to be busy
doing something else).

If you had read any of the stuff I pointed you at you would know that I
already made all those points 3 years ago. In a discussion with Sam less
than 6 months ago he was still uneasy about putting this into SDL.

Your response reads like you think I am arguing with you. If you read
the stuff I pointed you at you will find that I am in complete agreement
with you and have wanted these changes to be made for more than 3 years
now.

When I said “Good luck” I was being sincere. I wish you good luck in
getting this into SDL. I have tried, off and on, for 3 years and have
failed to get the change accepted. If I sound edgy or upset it is
because of the frustration of trying to get this bug fixed for so long.
Sadly to say, this bug has become a hot button subject for me.

– Marc A. Pelletier

Good Luck,

	Bob PendletonOn Tue, 2005-09-13 at 14:41 -0400, Marc A. Pelletier wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

–
±-------------------------------------+

13

Antonio SJ Musumeci wrote:

That’s what I meant. The size is set at compile time… not runtime. But
why?

Oh. I expect you should ask the original author for that. Maybe there were
performance or memory footprint considerations?

– Marc A. Pelletier

14

“If you had read any of the stuff I pointed you at you would know that I
already made all those points 3 years ago. In a discussion with Sam less
than 6 months ago he was still uneasy about putting this into SDL.”

maybe i might be sounding a little democratic here, i apologise for that,
but can’t the users (SDL Developers ) have some kind of vote or something as
to whether it is or isn’t a Bug or whether it should be included.

not taking away from Sam Lantiniga and the library…

15 
    "If you had read any of the stuff I pointed you at you would
    know that I
    already made all those points 3 years ago. In a discussion
    with Sam less 
    than 6 months ago he was still uneasy about putting this into
    SDL."

maybe i might be sounding a little democratic here, i apologise for
that, but can’t the users (SDL Developers ) have some kind of vote or
something as to whether it is or isn’t a Bug or whether it should be
included.

not taking away from Sam Lantiniga and the library…

Here I have to go along with Sam 100%. Software development is not a
democratic process. There have to be people who are concerned about the
overall architecture and design of the library. Those people, Sam, and
the other long time developers, know why things are done the way they
are and they know what has to be done to maintain compatibility. They
have the big view. Even I, with my huge ego and vast knowledge :slight_smile: have
to admit that I do not know the complete story and must accept the
decisions of those who do.

OTOH, if a lot of people jump in and say they want the feature, then it
will get more weight than if it is just you and I. The fact is that very
few people seem to need it, and those that do need seem to be happy to
use my library. But, if it breaks SDL on a widely used platform, there
is good reason not to add it in.

I am hoping we can get this into SDL 2.0 even if we can’t get it into a
current version of SDL.

I hope you understand that I have no authority one way or the other over
SDL.

	Bob PendletonOn Wed, 2005-09-14 at 23:54 +0100, Brian Barrett wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

16

While I agree that compatibility is important… it shouldnt keep from
improving the library as a whole. My biggest problem with SDL is it’s
general lack of a feature query system. It would seem to me the most
compatible and maintainable way of dealing with many platforms would be
like OpenGL does. Certain features are globally available… but
everything else needs to be checked at runtime. I find it safer and
easier to work with. If SDL supports not including certain subsystems…
why must we wait till link time to find that out? Have dummy functions
and a way to see if it exists. Why must things like video and audio
drivers not be settable but by environmental variables? Why cant we find
out what are available? If the Windows blitter doesnt use assembly
optimized code… or support hardware surfaces… I’d like to know this
at runtime. Or clock resolution. Anything not consistent platform to
platform. It seems many of the questions this mailing list gets could be
answered if there was was a feature querying system. Maybe not the why
feature X isnt supported but at least the fact that it isnt is not
hidden. I really hope that when and if SDL2 happens… we can include
such a system.

Bob Pendleton wrote:> On Wed, 2005-09-14 at 23:54 +0100, Brian Barrett wrote:

   "If you had read any of the stuff I pointed you at you would
   know that I
   already made all those points 3 years ago. In a discussion
   with Sam less 
   than 6 months ago he was still uneasy about putting this into
   SDL."

maybe i might be sounding a little democratic here, i apologise for
that, but can’t the users (SDL Developers ) have some kind of vote or
something as to whether it is or isn’t a Bug or whether it should be
included.

not taking away from Sam Lantiniga and the library…

Here I have to go along with Sam 100%. Software development is not a
democratic process. There have to be people who are concerned about the
overall architecture and design of the library. Those people, Sam, and
the other long time developers, know why things are done the way they
are and they know what has to be done to maintain compatibility. They
have the big view. Even I, with my huge ego and vast knowledge :slight_smile: have
to admit that I do not know the complete story and must accept the
decisions of those who do.

OTOH, if a lot of people jump in and say they want the feature, then it
will get more weight than if it is just you and I. The fact is that very
few people seem to need it, and those that do need seem to be happy to
use my library. But, if it breaks SDL on a widely used platform, there
is good reason not to add it in.

I am hoping we can get this into SDL 2.0 even if we can’t get it into a
current version of SDL.

I hope you understand that I have no authority one way or the other over
SDL.

  Bob Pendleton

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

17

While I agree with your main point (I’ve been frustrated in the past by
not being able to write code that can know in advance if fullscreen
switch would work, for example), I would suggest that a main point of
SDL is to handle this kind of this internally. I believe that is a
central point of its design.

I think this is good. For example, if the extreme of what you are
suggesting is implemented, it’s conceivable that a number of SDL apps
would simply query for and require so many extensions and features that
the app would no longer be as portable as SDL could otherwise allow.

While I support the addition of some of this querying, I would caution
against its overuse. SDL’s ‘S’ does stand for ‘Simple’ - at least last
I checked.On Thu, Sep 15, 2005 at 12:05:34PM -0400, Antonio SJ Musumeci wrote:

While I agree that compatibility is important… it shouldnt keep from
improving the library as a whole. My biggest problem with SDL is it’s
general lack of a feature query system. It would seem to me the most
compatible and maintainable way of dealing with many platforms would
be like OpenGL does. Certain features are globally available… but
everything else needs to be checked at runtime. I find it safer and
easier to work with. If SDL supports not including certain
subsystems… why must we wait till link time to find that out? Have
dummy functions and a way to see if it exists. Why must things like
video and audio drivers not be settable but by environmental
variables? Why cant we find out what are available? If the Windows
blitter doesnt use assembly optimized code… or support hardware
surfaces… I’d like to know this at runtime. Or clock resolution.
Anything not consistent platform to platform. It seems many of the
questions this mailing list gets could be answered if there was was a
feature querying system. Maybe not the why feature X isnt supported
but at least the fact that it isnt is not hidden. I really hope that
when and if SDL2 happens… we can include such a system.

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050915/377cafe8/attachment.pgp

18

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Steaphan Greene wrote:>

While I agree with your main point (I’ve been frustrated in the past by
not being able to write code that can know in advance if fullscreen
switch would work, for example), I would suggest that a main point of
SDL is to handle this kind of this internally. I believe that is a
central point of its design.

I think this is good. For example, if the extreme of what you are
suggesting is implemented, it’s conceivable that a number of SDL apps
would simply query for and require so many extensions and features that
the app would no longer be as portable as SDL could otherwise allow.

While I support the addition of some of this querying, I would caution
against its overuse. SDL’s ‘S’ does stand for ‘Simple’ - at least last
I checked.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

19

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050915/828506fd/attachment.pgp

20

I agree; I would love a robust runtime query system in SDL, maybe

char* SDL_SystemQuery(char* capability);
…
if(atoi(SDL_SystemQuery(“DESKTOP_RESOLUTION_W”) == 1024) {
printf(“I don’t like people using 1024x768 desktop resolution, bye.\n”);
return;
}

or

if(!SDL_SystemQuery(“ALPHABLEND_HW_HW_ACCEL”)) {
printf(“Alpha blending is not hardware accelerated, get some new gfx h/w!\n”);
printf(“I will run the program anyway, I’ve warned you.\n”);
}

or whatever. Lots of flags, yes :slight_smile:

Best of both worlds would be if SDL used the current
"fall-back-to-closest-match" system of today, but add APIs for
querying reliably also. Then an application programmer could choose to
play it the portable way and continue to run the program even if the
best match isn’t available, or quit if he pleases.

/OlofOn 9/16/05, Steaphan Greene wrote:

On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDKg/PTFyjetLgWh8RAt1bAKCnLLHfr8bpJwkHplQ98t3O8vwjywCfU/N9
VglJf51/YM54aS6MI4kuwBo=
=H0Nv
-----END PGP SIGNATURE-----

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl