Some multithreaded improvement to the event queue

SDL Development
61

Le Fri, 30 Sep 2005 14:42:41 -0500
Bob Pendleton a ?crit:

  • OpenGL context loss on SDL_SetVideoMode

Reloading all textures every time the window is resized, for
example, is something that should be avoided if possible …
A function that returns true if the context was lost on the
last SetVideoMode could be nice.

Ok, this one makes some sense. Although, AFAIK, there is only one OS
that does this. It would be nice to query for that bug.

See this thread about this specific issue:

Atm, even if only win32 driver destroys the OpenGL context, there may be
some future drivers for some unknown target that may do the same.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

62

Funny thing is that SDL_WM_ToggleFullScreen is the prime example
used to justify the need of a query system in SDL. The thing is, it
is documented that it only works on one kind of system, so a simple
#ifdef (or the equivalent) is all that your code needs to determine
if you have the feature or not.

Yes, but surely you’d agree that that’s not a good, portable
solution. SDL_WM_ToggleFullScreen may become usable on other platforms
in the future (and/or it might conceivably become unavailabile on
later versions of the current platform). It would definitely be better
if you could test for the feature directly, rather than hardcode an
assumption that it exists on one platform.

SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
a similar feature for features like full-screen toggling would be a
good thing, I think.

I would also love it if SDL could provide information on audio latency
issues, although I assume that acquiring such information just isn’t
easily available. But if it were, surely we can agree that making such
information available to the programmer would only improve
portability.

b

63

Brian Raiter wrote:

Yes, but surely you’d agree that that’s not a good, portable
solution. SDL_WM_ToggleFullScreen may become usable on other platforms
in the future (and/or it might conceivably become unavailabile on
later versions of the current platform). It would definitely be better
if you could test for the feature directly, rather than hardcode an
assumption that it exists on one platform.

I agree that conditional compilation is not the answer to this
situation. However, what’s wrong with just trying
SDL_WM_ToggleFullScreen falling back to SDL_SetVideoMode if it fails?
The only situation I can think of where that wouldn’t work is if you
didn’t write the fallback code and want to disable the ability to switch
between full-screen and windowed mode entirely.

SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
a similar feature for features like full-screen toggling would be a
good thing, I think.

For the record, I consider SDL_MUSTLOCK() a mistake. 90% of the time it
is used for code like this:

if (SDL_MUSTLOCK(s)) SDL_LockSurface(s);

…which is just a waste of keystrokes, since SDL_LockSurface(s) works
even if SDL_MUSTLOCK(s) returns false. I can think of two legitimate
uses, one of which is purely for error checking
(assert(!SDL_MUSTLOCK(s))) and the other is completely marginal (i.e.
completely different code paths optimized for the different performance
characteristics of surfaces that require locking and those that don’t).

Which is not to say that a query system wouldn’t be a worthwhile
addition to SDL. However, it would need to be carefully designed to
expose useful information instead just opening up a bunch of useless
implementation details.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

64

I think Rainer is right about the query system, and how it should not
open up a bunch of useless things. In addition to that, I think that
if this is added to SDL, it should likely be in the form of an addon
library, and should be kept as streamlined as possible. SDL is built
the way it is for a reason. Anyone can make additions to SDL through a
library without it even having to be checked into a CVS/SVN server, or
approved by a larger audience. I can almost guarantee (and anyone who’s
even visited the freenode irc channel can likely verify) that newbies
with no idea of what they’re doing would misuse the functions to the
point where they’d come crying to us to figure out why their program is
slowing down, not working “the way it should”, or just generally saying
that there’s too much to learn. (Yes, I’ve actually heard that about
SDL…shudder) I think the big thing here is that whoever wants these
features added should really put in the effort and either at least try
to submit a patch which covers some of the functionality, or create an
addon library (the better option, in my opinion) that does the job. If
we just sit back and complain about what SDL can’t do, rather than
adding that functionality for ourselves and others, we do nothing to
help a great development tool/library such as SDL.

-Elden

Rainer Deyke wrote:> Brian Raiter wrote:

Yes, but surely you’d agree that that’s not a good, portable
solution. SDL_WM_ToggleFullScreen may become usable on other platforms
in the future (and/or it might conceivably become unavailabile on
later versions of the current platform). It would definitely be better
if you could test for the feature directly, rather than hardcode an
assumption that it exists on one platform.

I agree that conditional compilation is not the answer to this
situation. However, what’s wrong with just trying
SDL_WM_ToggleFullScreen falling back to SDL_SetVideoMode if it fails?
The only situation I can think of where that wouldn’t work is if you
didn’t write the fallback code and want to disable the ability to
switch between full-screen and windowed mode entirely.

SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
a similar feature for features like full-screen toggling would be a
good thing, I think.

For the record, I consider SDL_MUSTLOCK() a mistake. 90% of the time
it is used for code like this:

if (SDL_MUSTLOCK(s)) SDL_LockSurface(s);

…which is just a waste of keystrokes, since SDL_LockSurface(s) works
even if SDL_MUSTLOCK(s) returns false. I can think of two legitimate
uses, one of which is purely for error checking
(assert(!SDL_MUSTLOCK(s))) and the other is completely marginal (i.e.
completely different code paths optimized for the different
performance characteristics of surfaces that require locking and those
that don’t).

Which is not to say that a query system wouldn’t be a worthwhile
addition to SDL. However, it would need to be carefully designed to
expose useful information instead just opening up a bunch of useless
implementation details.

65

Therein lies the problem. How do you build an SDL internal as an external
library? I ran into the same problem developing SDL_audioin – two things
initializing/using the same libraries it doesn’t always work, and results in
a lot of code duplication anyway.On September 30, 2005 11:00 pm, Elden Armbrust wrote:

I think Rainer is right about the query system, and how it should not
open up a bunch of useless things. In addition to that, I think that
if this is added to SDL, it should likely be in the form of an addon
library, and should be kept as streamlined as possible.

66

Tyler Montbriand wrote:> On September 30, 2005 11:00 pm, Elden Armbrust wrote:

I think Rainer is right about the query system, and how it should not
open up a bunch of useless things. In addition to that, I think that
if this is added to SDL, it should likely be in the form of an addon
library, and should be kept as streamlined as possible.

Therein lies the problem. How do you build an SDL internal as an external
library? I ran into the same problem developing SDL_audioin – two things
initializing/using the same libraries it doesn’t always work, and results in
a lot of code duplication anyway.

I suggested a possible solution before. We could have SDL expose hooks
to platform-specific structures. Then the addon libs are free to do what
they will :

For example, I think it would be enough to add a couple of hooks like
void* SDL_GetVideoHook() and SDL_GetAudioHook(). These functions would
return a pointer to a platform-specific struct, which contains
sufficient information, like the video device context or the audio
context… The add-on library can then query this hook, and use
platform-dependent code accordingly.

Now, maybe this thing could turn into a big mess. Maybe not, I don’t know.

Stephane

67

i don’t think a feature query system would add much to SDL, apart from
bloat…

but two things.

the whole SDL_WM_ToggleFullScreen() thing.

if it can only be supported on a limited range of platforms, maybe we think
about modifying what this function does. this is a change for the
binary-compatability-breaking version of SDL.

why dont we change it so that it performs the toggle and passes back a brand
new surface pointer?

instead of practically everyone who uses this function and who wants to
remain platform independant have to implement their own.

on X11, etc the code would just be the existing code.

and on the GL contex being lost, would that be suitable for an SDL_Event? we
have several reserved slots.

68

Brian Barrett wrote:

i don’t think a feature query system would add much to SDL, apart from
bloat…

but two things.

the whole SDL_WM_ToggleFullScreen() thing.

if it can only be supported on a limited range of platforms, maybe we think
about modifying what this function does. this is a change for the
binary-compatability-breaking version of SDL.

why dont we change it so that it performs the toggle and passes back a brand
new surface pointer?

Actually SDL_WM_ToggleFullScreen is just a bad idea. If you’re running
in a window, you want to match the pixel format of the desktop. If
you’re running full-screen, you want to run at the color depth for which
your game is optimized, usually with hardware surfaces (currently not
available in windowed mode) and/or page flipping. That means you should
always use SDL_SetVideoMode to switch between windowed mode and
full-screen mode, and you should always reload your graphics afterwards.

SDL_WM_ToggleFullScreen exists because on some very limited platforms,
you don’t get any hardware surfaces, you don’t get page flipping, and
you might even be unable to change the color depth of the display. On
those (legacy) systems, SDL_WM_ToggleFullScreen saves you a bit of time
by allowing you to reuse the display surface and any graphics you have
loaded. However, SDL_SetVideoMode is the correct and portable way to
toggle full-screen mode.

Hopefully SDL_WM_ToggleFullScreen will be gone entirely in SDL 2.0.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

69

Funny thing is that SDL_WM_ToggleFullScreen is the prime example
used to justify the need of a query system in SDL. The thing is, it
is documented that it only works on one kind of system, so a simple
#ifdef (or the equivalent) is all that your code needs to determine
if you have the feature or not.

Yes, but surely you’d agree that that’s not a good, portable
solution. SDL_WM_ToggleFullScreen may become usable on other platforms
in the future (and/or it might conceivably become unavailabile on
later versions of the current platform). It would definitely be better
if you could test for the feature directly, rather than hardcode an
assumption that it exists on one platform.

Look, I have proposed a basic API for a query system and I have asked
for examples of things that would be worth querying. So far I have heard
of two things that may be worth querying that are not already in SDL.

SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
a similar feature for features like full-screen toggling would be a
good thing, I think.

Yes, SDL already provides some very powerful querying capabilities. So
far people have come up with two features that may justify adding
queries to SDL. That is a far cry from what people started out asking
for at the beginning of this thread.

I would also love it if SDL could provide information on audio latency
issues, although I assume that acquiring such information just isn’t
easily available. But if it were, surely we can agree that making such
information available to the programmer would only improve
portability.

What is the problem here? Latency is directly related to the size of the
buffers the programmer is handing to the sound system. It may also be
affected by handing off samples that have to be converted to a different
sample size. But, seriously, I have never seen or heard of a situation
where the latency wasn’t directly related to the size of the buffers.
Please, give me an example where that is not the case. I’ve only been
working with sound since the original PC came out (yes, I have written
code that can play back a sampled sound by tweaking timer chip under
DOS), I may have missed some total messed up sound system somewhere.
Please stop listing this as something you want to query until you show
why what you want to know isn’t already under your control.

	Bob PendletonOn Fri, 2005-09-30 at 14:38 -0700, Brian Raiter wrote:

b

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

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

70

i don’t think a feature query system would add much to SDL, apart from
bloat…

but two things.

the whole SDL_WM_ToggleFullScreen() thing.

if it can only be supported on a limited range of platforms, maybe we
think about modifying what this function does. this is a change for
the binary-compatability-breaking version of SDL.

why dont we change it so that it performs the toggle and passes back a
brand new surface pointer?

instead of practically everyone who uses this function and who wants
to remain platform independant have to implement their own.

on X11, etc the code would just be the existing code.

and on the GL contex being lost, would that be suitable for an
SDL_Event? we have several reserved slots.

These are great ideas. They have been proposed before. No one has
implemented them because they cause a change in the binary interface.
They could be included in the future 2.0 release.

But, this is the way I like to see people think and I want to hit myself
for not thing like this myself. Don’t add queries to detect broken
features, fixthebrokenfeatures*.

	Bob PendletonOn Sat, 2005-10-01 at 21:00 +0100, Brian Barrett wrote:

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

71

I’ve typically used different buffer sizes for Win32 and Linux, since
on Win32 smaller buffers (I think) sound all staticy and choppy.

More importantly, though, the same app ran on different Win32 setups
works on some, and doesn’t on others.

When I eventually get around to re-releasing all of my SDL games, I’ll
probably add a “–soundbuffer” option, where users can tweak it if their
box is having issues. Lame, but…

-bill!On Mon, Oct 03, 2005 at 03:40:26PM -0500, Bob Pendleton wrote:

But, seriously, I have never seen or heard of a situation
where the latency wasn’t directly related to the size of the buffers.
Please, give me an example where that is not the case. I’ve only been
working with sound since the original PC came out (yes, I have written
code that can play back a sampled sound by tweaking timer chip under
DOS), I may have missed some total messed up sound system somewhere.
Please stop listing this as something you want to query until you show
why what you want to know isn’t already under your control.

72

P? Fri, 30 Sep 2005 21:42:41 +0200, skrev Bob Pendleton
:

If the only available video driver is aalib (or caca, etc), I
might want to show a specialized curses-based UI in stead of
having SDL convert images to ultra-low-quality ascii.

I don’t believe this is a serious problem. If it is, then it can be
solved by the existing query functions in SDL.

Really ? How ? (I figured ListModes could at least give a hint by
returning very low resolutions, but that didn’t work out. It acts
like aalib is a regular pixel display capable of high resolutions.)

If audio latency is large, I might want to delay video a couple
of frames to get better synchronization with video.

Are you talking about video latency or audio latency? Audio latency can
be controlled by choosing small buffers. Video latency is nearly
unpredictable, so you pretty much have to adjust your video output to
match the audio stream.

I was talking about audio latency. I know latency can be controlled
by using small buffers as you said, but that doesn’t help much when
the audio driver uses its own buffers or even layers of them – you
can only control the topmost layer. Doesn’t artsd do this, for
example ? Not to mention network audio … (Note, I’m not an audio
guru, so apologies if any of this is completely wrong).

  • Gerry
73

Look, I have proposed a basic API for a query system and I have asked
for examples of things that would be worth querying. So far I have heard
of two things that may be worth querying that are not already in SDL.

One thing which I think was mentioned somewhere early in this thread, but
which might have been forgotten somewhere (or I’m just redundant, haven’t
been reading this thread all that carefully), is querying for a list of
compiled-in video (and audio?) drivers. This wouldn’t introduce any binary
compatibility break as long as we still use the ugly env.variable trick to
choose which one to be used.

// MartinOn Mon, 3 Oct 2005, Bob Pendleton wrote:

74

I would also love it if SDL could provide information on audio latency
issues, although I assume that acquiring such information just isn’t
easily available.

What is the problem here?

In short, the minimum buffer size that you can ask for without
incurring negative side effects.

I lowered my requested audio buffer size in my SDL game in order to
avoid delays between user action and sound effect. Larger buffer sizes
caused consistent delays that resulted in distracting arrythmic
effects.) When I released that version, I learned that on numerous
Windows platforms the sound was strangely noisy and filled with
bizarre echo effects. I eventually learned that you need to stay above
a certain buffer size on Windows or else your sound gets badly
mangled. Unfortunately there’s no way to programmatically determine
what this minimum size is. So, to fix this I had to increase the
default audio buffer size, and also allow the user to increase the
size further as necessary.

To repeat myself, I imagine that SDL has no cheap way of determining
the minimum mangle-free audio buffer size, so this probably isn’t
something that can be added to a query system. But if it could be,
then surely that’s something that should be available to the
programmer somehow.

The above wasn’t directed at you, Bob Pendleton. It was just offered
as an example of how certain kinds of querying can in fact help make a
program more portable. If I could query the minimum audio buffer size,
for example, my program could choose to add or remove certain sound
effects that degrade more noticeably with larger buffer sizes. Etc
etc.

b

75

But, seriously, I have never seen or heard of a situation
where the latency wasn’t directly related to the size of the buffers.
Please, give me an example where that is not the case. I’ve only been
working with sound since the original PC came out (yes, I have written
code that can play back a sampled sound by tweaking timer chip under
DOS), I may have missed some total messed up sound system somewhere.
Please stop listing this as something you want to query until you show
why what you want to know isn’t already under your control.

I’ve typically used different buffer sizes for Win32 and Linux, since
on Win32 smaller buffers (I think) sound all staticy and choppy.

More importantly, though, the same app ran on different Win32 setups
works on some, and doesn’t on others.

When I eventually get around to re-releasing all of my SDL games, I’ll
probably add a “–soundbuffer” option, where users can tweak it if their
box is having issues. Lame, but…

Thank you, that is a great example. What can be queried on Windows that
could help you solve this problem? What parts of the Win32 API need to
be exposed to SDL to solve let the programmer avoid having to have a
–soundbuffer option? Can the problem be corrected by rewriting parts of
the SDL sound library without resorting to adding a query system? Do
other OSes have the same problems?

Bob PendletonOn Mon, 2005-10-03 at 13:59 -0700, Bill Kendrick wrote:

On Mon, Oct 03, 2005 at 03:40:26PM -0500, Bob Pendleton wrote:

-bill!

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

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

76

P? Fri, 30 Sep 2005 21:42:41 +0200, skrev Bob Pendleton
<@Bob_Pendleton>:

If the only available video driver is aalib (or caca, etc), I
might want to show a specialized curses-based UI in stead of
having SDL convert images to ultra-low-quality ascii.

I don’t believe this is a serious problem. If it is, then it can be
solved by the existing query functions in SDL.

Really ? How ? (I figured ListModes could at least give a hint by
returning very low resolutions, but that didn’t work out. It acts
like aalib is a regular pixel display capable of high resolutions.)

How about SDL_VideoDriverName()?

If audio latency is large, I might want to delay video a couple
of frames to get better synchronization with video.

Are you talking about video latency or audio latency? Audio latency can
be controlled by choosing small buffers. Video latency is nearly
unpredictable, so you pretty much have to adjust your video output to
match the audio stream.

I was talking about audio latency. I know latency can be controlled
by using small buffers as you said, but that doesn’t help much when
the audio driver uses its own buffers or even layers of them – you
can only control the topmost layer.

I see your point. If you are using a buggy sound system then you can run
into the problems you are describing. Short of telling the user to
change their sound system I’m not sure what a query system would tell
you that would help you adjust for a buggy sound system.

Most, nearly all, sound systems know that near real time response it
required on a computer and will merge your buffers into their larger
buffers so that they will begin playing ASAP.

Doesn’t artsd do this, for
example ? Not to mention network audio … (Note, I’m not an audio
guru, so apologies if any of this is completely wrong).

Latency and networking go hand in hand. I have trouble believing that is
something that can be addressed by SDL. But, I am willing, even eager,
to be shown that I am wrong.

Give me an example of the types of queries supported by the sound
libraries that would help you solve these problems. I will keep arguing
against the query system until people provide concrete examples of
queryable information that would let them solve real problems. So far
the two concrete examples that have been identified are things that
should either be fixed (if only it were possible), removed from SDL
(IMHO), or addressed in a different way.

	Bob PendletonOn Tue, 2005-10-04 at 01:38 +0200, Gerry JJ wrote:
  • Gerry

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

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

77

Look, I have proposed a basic API for a query system and I have asked
for examples of things that would be worth querying. So far I have heard
of two things that may be worth querying that are not already in SDL.

One thing which I think was mentioned somewhere early in this thread, but
which might have been forgotten somewhere (or I’m just redundant, haven’t
been reading this thread all that carefully), is querying for a list of
compiled-in video (and audio?) drivers. This wouldn’t introduce any binary
compatibility break as long as we still use the ugly env.variable trick to
choose which one to be used.

I don’t recall seeing that proposed, but I can see its value and I just
checked the source code, it would be nearly trivial to add, and as you
pointed out, it wouldn’t cause any binary compatibility problems. Not to
mention that it would add a tiny amount of code to the library.

I think adding the functions to support querying the list of available
audio and video drivers is a good idea. I think that an API should be
added to select one of them without having to use the environment
variable trick. There are comments in the source saying that that is
going to be fixed some day, perhaps today is the day?

Thank you. When people, like you, find specific, concrete problems, it
is easy to find concrete solutions.

	Bob PendletonOn Tue, 2005-10-04 at 09:26 +0300, Martin Storsj? wrote:

On Mon, 3 Oct 2005, Bob Pendleton wrote:

// Martin

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

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

78

I would also love it if SDL could provide information on audio latency
issues, although I assume that acquiring such information just isn’t
easily available.

What is the problem here?

In short, the minimum buffer size that you can ask for without
incurring negative side effects.

I lowered my requested audio buffer size in my SDL game in order to
avoid delays between user action and sound effect. Larger buffer sizes
caused consistent delays that resulted in distracting arrythmic
effects.) When I released that version, I learned that on numerous
Windows platforms the sound was strangely noisy and filled with
bizarre echo effects. I eventually learned that you need to stay above
a certain buffer size on Windows or else your sound gets badly
mangled. Unfortunately there’s no way to programmatically determine
what this minimum size is. So, to fix this I had to increase the
default audio buffer size, and also allow the user to increase the
size further as necessary.

To repeat myself, I imagine that SDL has no cheap way of determining
the minimum mangle-free audio buffer size, so this probably isn’t
something that can be added to a query system. But if it could be,
then surely that’s something that should be available to the
programmer somehow.

The above wasn’t directed at you, Bob Pendleton.

Thank you. I do not take this discussion personally.

It was just offered
as an example of how certain kinds of querying can in fact help make a
program more portable. If I could query the minimum audio buffer size,
for example, my program could choose to add or remove certain sound
effects that degrade more noticeably with larger buffer sizes. Etc
etc.

I understand what you are saying. And I am very glad to have your
example of what you would like to be able to query.

Can you (or anyone at all) point at an API in any OS or library that
gives you the information you want? If you can, then we can find a way
to make that information available through SDL. If not, then we can’t.
It is as simple as that. SDL doesn’t have any magic for digging out
information. It has to use what the APIs of the different libraries and
OSes provide. Also, adding a call into the low level audio drivers means
a fairly large change in SDL and affects the sound code for every driver
used on every platform.

Lets not imagine that the problem is unsolvable, lets see if we can
solve it.

	Bob PendletonOn Tue, 2005-10-04 at 10:31 -0700, Brian Raiter wrote:

b

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

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

79

Really ? How ? (I figured ListModes could at least give a hint by
returning very low resolutions, but that didn’t work out. It acts
like aalib is a regular pixel display capable of high resolutions.)

Not that I disagree with you on this point, but anyone that compiles
aalib into their SDL gets what they deserve when apps don’t work correctly.

It’s a cute hack, but it shouldn’t go into a serious build of the
library, and NEVER into a distribution’s packages.

imho.

–ryan.

80

This was brought up on at least one occasion by myself and seemed to be
ignored which is why I was getting a little annoyed as even the comments
in the code note it should be fixed.

Bob Pendleton wrote:> On Tue, 2005-10-04 at 09:26 +0300, Martin Storsj? wrote:

On Mon, 3 Oct 2005, Bob Pendleton wrote:

Look, I have proposed a basic API for a query system and I have asked
for examples of things that would be worth querying. So far I have heard
of two things that may be worth querying that are not already in SDL.

One thing which I think was mentioned somewhere early in this thread, but
which might have been forgotten somewhere (or I’m just redundant, haven’t
been reading this thread all that carefully), is querying for a list of
compiled-in video (and audio?) drivers. This wouldn’t introduce any binary
compatibility break as long as we still use the ugly env.variable trick to
choose which one to be used.

I don’t recall seeing that proposed, but I can see its value and I just
checked the source code, it would be nearly trivial to add, and as you
pointed out, it wouldn’t cause any binary compatibility problems. Not to
mention that it would add a tiny amount of code to the library.

I think adding the functions to support querying the list of available
audio and video drivers is a good idea. I think that an API should be
added to select one of them without having to use the environment
variable trick. There are comments in the source saying that that is
going to be fixed some day, perhaps today is the day?

Thank you. When people, like you, find specific, concrete problems, it
is easy to find concrete solutions.

  Bob Pendleton

// Martin

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