Re : Two threads updating screen

SDL Development
1

There had been a thread on that topic (and maybe more).
The conclusion was, in any case, if you can manage to avoid using threads, do it.
The main reason is that not all the OS will react the same way, depending on their
policy to switch between various tasks. Even if you clearly separate the display zones as disjoint areas, you may encounter troubles, especially if each thread does its own refresh ! Imagine there is a context switch while a refresh is performed, you might get stange glitches or something like that.
You have, at least, to synchronize the threads so that each update gets performed fully.
Correct me if I’m wrong.

Regards,

Julien

— En date de?: Mar 9.6.09, shree 0987 a ?crit?:de: shree 0987
Objet: [SDL] Two threads updating screen
?: “sdl at lists.libsdl.org”
Date: Mardi 9 Juin 2009, 15h16

Hello,
?
I have two threads updating?the screen. One is a UI thread, which puts a few buttons on the bottom of the screen and handles user input. The other is a graphics/video thread which updates the top?90% of the screen at 33ms intervals.

?
Is there a standard way of handling SDL_Flip or SDL_Updaterect in this case? I see the FAQ at http://www.libsdl.org/faq.php?action=listentries&category=2?says SDL video functions should be called only from the main thread.

?
Thanks,
–Shree.

-----La pi?ce jointe associ?e suit-----

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2

Hello,

I have two threads updating the screen. One is a UI thread, which
puts a few buttons on the bottom of the screen and handles user
input. The other is a graphics/video thread which updates the top
90% of the screen at 33ms intervals.

Is there a standard way of handling SDL_Flip or SDL_Updaterect in
this case? I see the FAQ at http://www.libsdl.org/faq.php?action=listentries&category=2
says SDL video functions should be called only from the main thread.

Not only should, it must be like this. (Not that I like it but there
seem to be no other way right now.)

Thanks,
–Shree.

There had been a thread on that topic (and maybe more).
The conclusion was, in any case, if you can manage to avoid using
threads, do it.

As far as I remember (and think of it), the conclusion was, it’s
simpler without thread and require often some redesign of some logic
in your game and some effort if you want to do it with threads. But
after all, threads have a lot of advantages (and that even on single
core machines; but they are dying out anyway, you almost cannot buy
any PC anymore nowadays which has just one core).

The main reason is that not all the OS will react the same way,
depending on their
policy to switch between various tasks. Even if you clearly separate
the display zones as disjoint areas, you may encounter troubles,
especially if each thread does its own refresh ! Imagine there is a
context switch while a refresh is performed, you might get stange
glitches or something like that.
You have, at least, to synchronize the threads so that each update
gets performed fully.
Correct me if I’m wrong.

Yes, you simply have to do the SDL_Flip in the main thread because of
the underlying framework which requires that (or is it just SDL
design? not sure on that).

If you are using software surfaces, writing to a surface from
different threads will work as long as you aren’t accessing the same
memory regions. Not sure if this is also true for hardware surfaces.
But you probably would like to have a different draw logic anyway with
hardware surfaces.–

Btw., as we are speaking about it: It has a lot of drawbacks that both
the SDL_Flip and the SDL event handling has to be done in the main
thread. SDL_Flip is often very slow (takes 40% runtime in our game)
and while you are doing it, you cannot get any events, which is bad.
In our game, we have the game logic and physics in a seperate thread
and we easily could respond to an event as soon as it arrives but
because of this problem, we always have to wait until SDL_Flip is
ready (or just do something else in the meanwhile) before we get new
SDL events.

3

Yes, you simply have to do the SDL_Flip in the main thread because of the
underlying framework which requires that (or is it just SDL design? not sure
on that).

If I recall, at least Windows has a number of problems if you use a
number of the GDI and message APIs from multiple threads. Some other
platforms (like BeOS I think) are fine with it, but the only way to be
portable is to avoid it.On Tue, Jun 9, 2009 at 10:16 AM, Albert Zeyer<albert.zeyer at rwth-aachen.de> wrote:

–
http://pphaneuf.livejournal.com/

4

why would you want to flip in two threads anyway? It seems like you would
have one thread undoing whatever the other thread did before the last flip and
then vise versa on the next flip.

As long as you’re using software surfaces and some locks to keep track of
who’s writing what, accessing the pixel buffer shouldn’t be a problem and you
can just have one thread do the actual flip.

With a hardware surface you have things like surface locking which would mean
you’d need to:

  1. lock mutex in thread A (thread B blocks waiting for mutex),
  2. lock surface,
  3. draw stuff,
  4. unlock surface,
  5. unlock mutex (thread B resumes),
  6. lock mutex in thread B (thread A blocks waiting for mutex),
  7. lock surface,
  8. draw stuff,
  9. unlock surface,
  10. flip,
  11. unlock mutex (thread A resumes)
  12. repeat…

At no point do you really have both threads running at once (which is kinda
the point of using threads), and it requires twice as many surface lock/unlock
operations than running in a single thread (lock/unlock can be pretty
expensive).On Tuesday, 9 June 2009 11:57:50 Pierre Phaneuf wrote:

On Tue, Jun 9, 2009 at 10:16 AM, Albert Zeyer<albert.zeyer at rwth-aachen.de> wrote:

Yes, you simply have to do the SDL_Flip in the main thread because of the
underlying framework which requires that (or is it just SDL design? not
sure on that).

If I recall, at least Windows has a number of problems if you use a
number of the GDI and message APIs from multiple threads. Some other
platforms (like BeOS I think) are fine with it, but the only way to be
portable is to avoid it.

5

Yes, you simply have to do the SDL_Flip in the main thread because
of the
underlying framework which requires that (or is it just SDL
design? not
sure on that).

If I recall, at least Windows has a number of problems if you use a
number of the GDI and message APIs from multiple threads. Some other
platforms (like BeOS I think) are fine with it, but the only way to
be
portable is to avoid it.

why would you want to flip in two threads anyway?

No, I don’t want that. But it would be nice if I can do the flipping
in another thread than the main thread (and only in that other
thread). And it would also be nice if I can have the event handling in
again another thread, so event handling accurance is not bounded by
screen blitting performance.

It seems like you would
have one thread undoing whatever the other thread did before the
last flip and
then vise versa on the next flip.

As long as you’re using software surfaces and some locks to keep
track of
who’s writing what, accessing the pixel buffer shouldn’t be a
problem and you
can just have one thread do the actual flip.

With a hardware surface you have things like surface locking which
would mean
you’d need to:

[…]

With hardware surfaces, it would be anyway not a good idea to write to
a surface from different threads. With hardware surfaces, each thread
would have it’s own surfaces and the final blitting to the screen is
done in the same thread where you do the SDL_Flip (at least that seems
to be the most reasonable way to do it).Am 09.06.2009 um 18:28 schrieb Kenneth Bull:

On Tuesday, 9 June 2009 11:57:50 Pierre Phaneuf wrote:

On Tue, Jun 9, 2009 at 10:16 AM, Albert Zeyer<@Albert_Zeyer> wrote:

6

why would you want to flip in two threads anyway?

No, I don’t want that. But it would be nice if I can do the flipping in another thread than the main thread (and only in that other thread). And it would also be nice if I can have the event handling in again another thread, so event handling accurance is not bounded by screen >blitting performance.

Yeah, I’ve been saying for a long time now that it doesn’t make any sense to do drawing and input handling in the same thread. There’s a SDL_Init flag for this, but apparently it only works on Linux. It would sure be nice if they got decoupled for more platforms.>----- Original Message ----

From: Albert Zeyer <albert.zeyer at rwth-aachen.de>
Subject: Re: [SDL] Re : Two threads updating screen