One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread? SDL’s strong orientation to an old-fashioned, single-threaded,
event-driven architecture is the reason I’m currently investigating
alternative libraries. It’s just getting more and more painful trying to
reconcile SDL with a heavily multithreaded application.
I could live with restricting all SDL calls to a single thread if I had
to, if only it didn’t have to be the main thread. Is there any prospect
of some relief on the horizon?
The reason for this was always named that most
OSes only support event handling and drawing
from the main thread.
For which OS is this true and for which false ?
It certainly isn’t true on Windows or Linux. I don’t have much
experience with Mac programming but I’m pretty sure it isn’t true there
either.
Actually, it is true (at least to quite some extent) for Mac OS X. Event
handling and drawing from threads other than the main thread is
problematic to put it nicely. At least that was the state of things 1-2
years ago, but I am pretty sure nothing changed in that regard. But I am
also sure that somebody will very soon correct me if I am wrong here :-).
Cheers,
MaxOn Mi, Oktober 10, 2007 12:08, Ross Smith wrote:
Torsten Giebl wrote:
Hello !
One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread? SDL’s strong orientation to an old-fashioned, single-threaded,
event-driven architecture is the reason I’m currently investigating
alternative libraries. It’s just getting more and more painful trying
to
reconcile SDL with a heavily multithreaded application.
I could live with restricting all SDL calls to a single thread if I had
to, if only it didn’t have to be the main thread. Is there any prospect
of some relief on the horizon?
The reason for this was always named that most
OSes only support event handling and drawing
from the main thread.
For which OS is this true and for which false ?
It certainly isn’t true on Windows or Linux. I don’t have much
experience with Mac programming but I’m pretty sure it isn’t true there
either.
One thing I’d like to know about SDL 1.3: Is it going to finally
remove
the restriction that SDL functions can only be called from the main
thread? SDL’s strong orientation to an old-fashioned, single-
threaded,
…
The reason for this was always named that most
OSes only support event handling and drawing
from the main thread.
For which OS is this true and for which false ?
It certainly isn’t true on Windows or Linux. I don’t have much
experience with Mac programming but I’m pretty sure it isn’t true
there
either.
Actually, it is true (at least to quite some extent) for Mac OS X.
Event
handling and drawing from threads other than the main thread is
problematic to put it nicely. At least that was the state of things
1-2
years ago, but I am pretty sure nothing changed in that regard. But
I am
also sure that somebody will very soon correct me if I am wrong
here :-).
Good guess. I haven’t seen any problems related to this in a
while on Mac
OS X, and I second the motion to modernize SDL’s threading capabilities.
Or do we still need to talk about BeOS, IRIX, OSF, AmigaOS, etc… ?
Well you can make another thread as the main thread. No one is forcing
you to consider the thread that can access SDL as the main thread.
I think that due to the modern HW SDL should provide more support for
multithreadded applications. This should be through API calls, so that
single threaded aplications don’t suffer from the support.
I think there are people like you who are much better at answering what
kind of API that should be.On Wednesday 10 October 2007, Ross Smith wrote:
One thing I’d like to know about SDL 1.3: Is it going to finally
remove the restriction that SDL functions can only be called from the
main thread? SDL’s strong orientation to an old-fashioned,
single-threaded, event-driven architecture is the reason I’m
currently investigating alternative libraries. It’s just getting more
and more painful trying to reconcile SDL with a heavily multithreaded
application.
I could live with restricting all SDL calls to a single thread if I
had to, if only it didn’t have to be the main thread. Is there any
prospect of some relief on the horizon?
One thing I’d like to know about SDL 1.3: Is it going to finally
remove the restriction that SDL functions can only be called from the
main thread? SDL’s strong orientation to an old-fashioned,
single-threaded, event-driven architecture is the reason I’m
currently investigating alternative libraries. It’s just getting more
and more painful trying to reconcile SDL with a heavily multithreaded
application.
I could live with restricting all SDL calls to a single thread if I
had to, if only it didn’t have to be the main thread. Is there any
prospect of some relief on the horizon?
Well you can make another thread as the main thread. No one is forcing
you to consider the thread that can access SDL as the main thread.
I think that due to the modern HW SDL should provide more support for
multithreadded applications. This should be through API calls, so that
single threaded aplications don’t suffer from the support.
I think there are people like you who are much better at answering
what
kind of API that should be.
Forgive my ignorance, but in all my study of games/graphics
programming (which, while extant is not by any stretch of the
imagination “comprehensive” or “in-depth”) I’ve not run across a
situation wherein the qualification that all drawing be performed in
a single thread would be terribly problematic to design around, if in
fact any conflict arose at all in the first place.
More simply, I’ve written multi-threaded programs, and never had to
deal with even WANTING to draw from another thread. I’ve always
designed my games to gather information for drawing each element
(which information may be changed in separate threads), and drawing
it; or elements that require a redraw request it and then the main
thread gets the request and redraws however is best/
Can you provide an example scenario wherein the ability to draw from
multiple threads becomes necessary? I’m still learning, so maybe I
haven’t yet run across it.
Thanks,
– ScottOn Oct 11, 2007, at 4:18 AM, Sami N??t?nen wrote:
One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread?
It certainly isn’t true on Windows or Linux.
On Linux you either have to do all your drawing calls from a single thread,
or add some really expensive locking and synchronization. This thread doesn’t
have to be the main thread, but there are big hoops to jump through if you
actually want multi-threaded 2D drawing.
On Windows, I think the same is true, although a bunch of the work is done
internally in the Windows API calls. I could be wrong about this.
On both platforms you have to jump through more hoops to get events on a
different thread than the graphics thread.
In SDL 1.3, the OpenGL context handling has been improved and all the normal
multi-threaded OpenGL context rules apply. I haven’t done any special work
to make the 2D code work on separate threads, but the architecture has changed
significantly and it may just work now.
See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
A while back it was proposed to have this (IMO, convoluted) system that had to
bind SDL_Surfaces to SDL_Textures, and whenever a change to the texture happened
you had to mess with the texture or something like that. I remember majority
opinion went against this. My main complaint was it would take the Simple out
Simple DirectMedia Layer.
Yep, this was dropped. There’s now the idea of a software surface, called
SDL_Surface, and a hardware texture, called SDL_Texture. You can’t mix the
two, although there are functions to convert a software surface into a video
texture.
Personally I think keeping them separate would be great. When I want to make a
quick and easy graphics app, I can just plain ol’ Surfaces. When I need more
speed and features, I can use the Textures.
Yep, that’s the idea.
Most importantly, will old SDL code still work on SDL 1.3 so I don’t have
completely redo the almost 40 programs I have on my site?
In general, yes. The biggest user-visible API change at this point is the
keyboard handling, which is splitting out text input from key up/down events.
Also, since we have an over all road map do we have estimated release date?
Maybe some time in 2008?
My family has another baby on the way, so there are no promises. However,
SDL 1.3 is pretty close to being ready for general testing, I’ve just been
procrastinating and working on World of Warcraft.
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
VERY well done for finally getting rid of SDLmain! SDLmain was a terrible idea!
Just awful, I can’t begin to tell you. How did that go forward for so long?
It was needed for DirectX 5, which is dropped in SDL 1.3.
So I guess my questions here are: will this 2D interface do HW
accelerated scaling?
Yes, where possible.
Will it support vbl syncing?
Possibly, there are a lot of situations where vbl syncing isn’t possible,
so if it’s added it’ll be after the core features are done.
Will we be able to tell when it cannot do these things?
Yes, of course.
And can we make the subsystem prefer Direct3d on windows?
It does right now. Direct3D and OpenGL are actually used to implement the
SDL 1.3 2D interface.
P.S. The mac, like on windows, now finally allows non-square pixel
video resolutions, but there’s no way to select them in SDL 1.2.
Not even by passing 0x0 which should give you the current mode.
If the current mode is “stretched” SDL resets the resolution to non-stretched.
Bugger.
Test case?
SDL letterboxing has never been terribly reliable. It didn’t position
properly with opengl and the handling of mouse events wasn’t consistent
across systems. To have opengl acceleration AND a constrained cursor
I had to roll my own letterboxing. It’s obviously a design pimple that
doesn’t play well with all the modes that SDL supports. Why not remove it?
I’d actually like to add an option to do aspect-constrained stretching,
and of course fix the issues in general. The move to largely using OpenGL
where possible to implement 2D video makes it a lot simpler to make sure
everything works consistently on the various platforms (sorta!)
That’s about it, keep up the great work, guys!
Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Will (or could) SDL 1.3 include any form of video playback API? I think it’s so important these days…
Ed___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now. http://uk.answers.yahoo.com/
One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread?
It certainly isn’t true on Windows or Linux.
On Linux you either have to do all your drawing calls from a single thread,
or add some really expensive locking and synchronization. This thread doesn’t
have to be the main thread, but there are big hoops to jump through if you
actually want multi-threaded 2D drawing.
On Windows, I think the same is true, although a bunch of the work is done
internally in the Windows API calls. I could be wrong about this.
On both platforms you have to jump through more hoops to get events on a
different thread than the graphics thread.
As I thought I’d made clear in my original post (but everybody seems to
be completely ignoring it), the real problem isn’t the restriction to a
single thread, but the fact that it has to be the main thread. It makes
it impossible to use the most natural program architecture, where main()
just spawns a bunch of threads and waits for them to finish. Working
around that was complicating my design unnecessarily. The more
sophistication I tried to put into my threading system, the more clunky
hacks I kept having to put in to work around SDL.
Even if SDL 1.3 fixes this, I don’t really want to put my project on
hold until a stable release of 1.3 is available. This issue is the main
reason I’m currently in the process of moving my project away from SDL
and using GLFW (http://glfw.sourceforge.net/) instead; GLFW still has
some of the same problems as SDL, but it doesn’t suffer from the “all
your base are belong to main()” problem that’s been causing me more
strife than everything else put together.
Sorry, there are a lot of things I like about SDL and I didn’t really
want to drop it, but I’m afraid this is the one killer feature I just
can’t live without. I wish you good luck.
As I thought I’d made clear in my original post (but everybody seems to
be completely ignoring it), the real problem isn’t the restriction to a
single thread, but the fact that it has to be the main thread.
This isn’t an SDL limitation, on platforms where you have to do that,
it’s a platform limitation. As far as I’m aware, SDL doesn’t care what
thread you use (but if the underlying platform will screw up, it can’t
help you)…so as a general guideline, SDL’s documentation tells you not
to do it.
Someone correct me if I’m wrong.
Sorry, there are a lot of things I like about SDL and I didn’t really
want to drop it, but I’m afraid this is the one killer feature I just
can’t live without. I wish you good luck.
First, it’s great that joysticks will now be hotpluggable, but I got
the impression that this is just for joysticks? I think it would
make sense to support this for other input devices too, specially now
that multiple mice and tablets will be supported. (Maybe even for
keyboards, for that 500-button gamepad … well, mice and tablets
would be useful at least).
Also, some tablets support more than just pressure and tilt for
certain tools (like z-rotation), and can also have extra buttons and
such on the tablet itself that’s not attached to a specific tool.
Will this also be supported? (Also, touch screens? Just a screen-
sized absolute-mode tablet, I suppose.)
Will there be a way to (accurately) mix more than two channels with
SDL_MixAudio?
Also, while I’m at it … have you considered splitting the RWops API to
be separate from SDL? Having a more generic API that could potentially
also be used by other things without necessarily depending on SDL
headers would be nice, I think. Permissive license a plus =)
(I’ve been fiddling with something like that myself, actually. Just a
struct with three functions: read, write, and control (for determining
supported ops, closing the stream, seeking, etc … easily customizable
and extensible), and an id. Then you can chain stuff together to do
things like on-the-fly delta patching with automatic buffering and
checksum generation, etc =))
As I thought I’d made clear in my original post (but everybody seems
to be completely ignoring it), the real problem isn’t the restriction
to a single thread, but the fact that it has to be the main thread.
at least for linux, this is not true. i have done it.
As I thought I’d made clear in my original post (but everybody seems
to be completely ignoring it), the real problem isn’t the restriction
to a single thread, but the fact that it has to be the main thread.
at least for linux, this is not true. i have done it.
And it’s not true also on win32.
At least with windib driver you have to call the SDL blit/event
functions in the thread that did SDL_SetVideoMode() but this can be not
the main thread.–
Bye,
Gabry
One thing I’d like to know about SDL 1.3: Is it going to finally
remove the restriction that SDL functions can only be called from
the main thread? SDL’s strong orientation to an old-fashioned,
single-threaded, event-driven architecture is the reason I’m
currently investigating alternative libraries. It’s just getting
more and more painful trying to reconcile SDL with a heavily
multithreaded application.
I could live with restricting all SDL calls to a single thread if
I had to, if only it didn’t have to be the main thread. Is there
any prospect of some relief on the horizon?
Well you can make another thread as the main thread. No one is
forcing you to consider the thread that can access SDL as the main
thread.
I think that due to the modern HW SDL should provide more support
for multithreadded applications. This should be through API calls,
so that single threaded aplications don’t suffer from the support.
I think there are people like you who are much better at answering
what
kind of API that should be.
Forgive my ignorance, but in all my study of games/graphics
programming (which, while extant is not by any stretch of the
imagination “comprehensive” or “in-depth”) I’ve not run across a
situation wherein the qualification that all drawing be performed in
a single thread would be terribly problematic to design around, if in
fact any conflict arose at all in the first place.
More simply, I’ve written multi-threaded programs, and never had to
deal with even WANTING to draw from another thread. I’ve always
designed my games to gather information for drawing each element
(which information may be changed in separate threads), and drawing
it; or elements that require a redraw request it and then the main
thread gets the request and redraws however is best/
This is the easiest way of doing things and as such it will be easier
than trying to spread the drawing around.
Can you provide an example scenario wherein the ability to draw from
multiple threads becomes necessary? I’m still learning, so maybe I
haven’t yet run across it.
Ther are some rare cases where that could be faster, but I can’t think
any that really would reguire or largely benefit by drawing from
multiple threads if it is using only single GFX-card.On Thursday 11 October 2007, Scott Harper wrote:
I haven’t seen any problems related to this in a
… well, mice and tablets