hi all,
Is there a ‘safe’ model for putting GUI processing in a thread, with SDL?
I don’t want my main thread (app thread) to be doing the graphics
processing … i have two other processing threads that run, and I
want them (plus my main thread) to be ‘coordinating’ with a 3rd
thread which does -all- GUI updates/SDL_Flip()'s, etc.
I’m a bit confused by the ‘intro notes’ - it states that there should
only be one GUI thread - and all examples seem to put this in the
main() runloop, but what I really want to do is fire up an SDL-only
handler thread and have it do all the SDL goodness. Is there a
standard model for threaded GUI stuff, maybe I should look at some
example somewhere?–
;
Jay Vaughan
— Jay Vaughan wrote:
hi all,
Is there a ‘safe’ model for putting GUI processing
in a thread, with SDL?
When you say GUI, do you mean graphics? Or an SDL
toolkit? There are various SDL GUI toolkit libraries
available.
I don’t want my main thread (app thread) to be doing
the graphics
processing … with a 3rd
thread which does -all- GUI updates/SDL_Flip()'s,
etc.
I suppose it depends partly on your graphics drawing
structure, and what threading library you’re using.
The best advice I can give you is to use a drawing
mutex to assure that the information pertaining to GUI
display doesn’t change while you’re drawing. See this
for more information:
http://sdldoc.csn.ul.ie/thread.php
I’m a bit confused by the ‘intro notes’ - it states
that there should
only be one GUI thread - and all examples seem to
put this in the
main() runloop, but what I really want to do is fire
up an SDL-only
handler thread and have it do all the SDL goodness.
This is correct. And you can do it the way you want,
it just may take a while. Feel free to email me your
work if you have any success.
Is there a
standard model for threaded GUI stuff, maybe I
should look at some
example somewhere?
It’s pretty straightforward as far as I’m concerned.
However perhaps you should consider speeding up your
program by including yet another thread that waits on
your drawing mutexes to do updates, or perhaps
double-buffering your graphics data.__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
When you say GUI, do you mean graphics? Or an SDL
toolkit? There are various SDL GUI toolkit libraries
available.
I mean ‘all graphics code’, since the only purpose of the graphics
code is (for me) to serve as an interface. i.e. there is no game
animation/GUI distinction.
I suppose it depends partly on your graphics drawing
structure, and what threading library you’re using.
The best advice I can give you is to use a drawing
mutex to assure that the information pertaining to GUI
display doesn’t change while you’re drawing. See this
for more information:
thanks for the link. its just that i don’t want my main app thread
to be the one doing the GUI update … I need graphics handling to be
independent of the rest of my main app, since it is also capable of
running stand-alone, so I do want to use mutex’es and cond_waits to
keep things sync’ed properly …
Is there a
standard model for threaded GUI stuff, maybe I
should look at some
example somewhere?
It’s pretty straightforward as far as I’m concerned.
However perhaps you should consider speeding up your
program by including yet another thread that waits on
your drawing mutexes to do updates, or perhaps
double-buffering your graphics data.
this is what i was shooting for, strategy wise. i could just have an
SDL_Thread fired off that does all graphics work. i understand that
this should be my -only- graphics thread, but does this mean i -can-
safely put SDL calls in a thread (not the main loop()) and just do it
all from a sync-locked thread that stays tight with the rest of my
main app?
the reason for my wanting to keep this separation is a) prog runs in
stand-alone ‘no-GUI’ mode, therefore just having a single thread that
does (or does not) fire up for graphics work is handy, and b) i have
other processing in my main() loop that is more important (to my app)
than the graphics updates, which is to say this isn’t like a game
where the only thing that matters is framerate … so maybe my model
doesn’t really match the typical SDL use?–
;
Jay Vaughan
When you say GUI, do you mean graphics? Or an SDL
toolkit? There are various SDL GUI toolkit libraries
available.
I mean ‘all graphics code’, since the only purpose of the graphics
code is (for me) to serve as an interface. i.e. there is no game
animation/GUI distinction.
I suppose it depends partly on your graphics drawing
structure, and what threading library you’re using.
The best advice I can give you is to use a drawing
mutex to assure that the information pertaining to GUI
display doesn’t change while you’re drawing. See this
for more information:
thanks for the link. its just that i don’t want my main app thread
to be the one doing the GUI update … I need graphics handling to be
independent of the rest of my main app, since it is also capable of
running stand-alone, so I do want to use mutex’es and cond_waits to
keep things sync’ed properly …
Is there a
standard model for threaded GUI stuff, maybe I
should look at some
example somewhere?
It’s pretty straightforward as far as I’m concerned.
However perhaps you should consider speeding up your
program by including yet another thread that waits on
your drawing mutexes to do updates, or perhaps
double-buffering your graphics data.
this is what i was shooting for, strategy wise. i could just have an
SDL_Thread fired off that does all graphics work. i understand that
this should be my -only- graphics thread, but does this mean i -can-
safely put SDL calls in a thread (not the main loop()) and just do it
all from a sync-locked thread that stays tight with the rest of my
main app?
The graphics must be done in the same thread that initialized SDL which
also must be the thread that handles SDL events. And, to the best of my
understanding, that must be the main thread. This isn’t really a
restriction caused by SDL, it is a restriction caused by various
operating systems.
the reason for my wanting to keep this separation is a) prog runs in
stand-alone ‘no-GUI’ mode, therefore just having a single thread that
does (or does not) fire up for graphics work is handy, and b) i have
other processing in my main() loop that is more important (to my app)
than the graphics updates, which is to say this isn’t like a game
where the only thing that matters is framerate … so maybe my model
doesn’t really match the typical SDL use?
It is kind of hard to get input events without a window so SDL doesn’t
work really well for what you are describing. SDL has the built in
assumption that you will have a GUI of some sort.
Bob PendletonOn Tue, 2004-06-15 at 09:37, Jay Vaughan wrote:
–
±-------------------------------------+
— Bob Pendleton wrote:
When you say GUI, do you mean graphics? Or an SDL
toolkit? There are various SDL GUI toolkit
libraries
available.
I mean ‘all graphics code’, since the only purpose
of the graphics
code is (for me) to serve as an interface. i.e.
there is no game
animation/GUI distinction.
I suppose it depends partly on your graphics
drawing
structure, and what threading library you’re
using.
The best advice I can give you is to use a
drawing
mutex to assure that the information pertaining
to GUI
display doesn’t change while you’re drawing. See
this
for more information:
thanks for the link. its just that i don’t want
my main app thread
to be the one doing the GUI update … I need
graphics handling to be
independent of the rest of my main app, since it
is also capable of
running stand-alone, so I do want to use mutex’es
and cond_waits to
keep things sync’ed properly …
Is there a
standard model for threaded GUI stuff, maybe
I
should look at some
example somewhere?
It’s pretty straightforward as far as I’m
concerned.
However perhaps you should consider speeding up
your
program by including yet another thread that
waits on
your drawing mutexes to do updates, or perhaps
double-buffering your graphics data.
this is what i was shooting for, strategy wise. i
could just have an
SDL_Thread fired off that does all graphics work.
i understand that
this should be my -only- graphics thread, but does
this mean i -can-
safely put SDL calls in a thread (not the main
loop()) and just do it
all from a sync-locked thread that stays tight
with the rest of my
main app?
The graphics must be done in the same thread that
initialized SDL which
also must be the thread that handles SDL events.
And, to the best of my
understanding, that must be the main thread. This
isn’t really a
restriction caused by SDL, it is a restriction
caused by various
operating systems.
It should still be easy enough to make the contents of
his current “main loop” a function, and his SDL
routines another function. Then if it’s run in non
graphical mode, his main routine can simply invoke his
"main loop," function; but if it’s run in graphical
mode, and he must use his main thread to do SDL
related tasks, then he can then spawn a new thread
running his “main loop” routine, and in his primary
thread launch his SDL initialize–loop–uninitialize
routine.
You could possibly encapsulate all of the game data
that will be displayed on screen into a single object,
and double buffer it so that it’s not accessed by two
threads simultaneously. This is what I meant by
"double buffering graphics data." Perhaps there is a
better word for it?
the reason for my wanting to keep this separation
is a) prog runs in
stand-alone ‘no-GUI’ mode, therefore just having a
single thread that
does (or does not) fire up for graphics work is
handy, and b) i have
other processing in my main() loop that is more
important (to my app)
than the graphics updates, which is to say this
isn’t like a game
where the only thing that matters is framerate …
so maybe my model
doesn’t really match the typical SDL use?
It is kind of hard to get input events without a
window so SDL doesn’t
work really well for what you are describing. SDL
has the built in
assumption that you will have a GUI of some sort.
Yeah I am kind of curious about this. What does your
app do exactly?> On Tue, 2004-06-15 at 09:37, Jay Vaughan wrote:
Bob Pendleton
–
±-------------------------------------+
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo