Two threads updating screen

SDL Development
1

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.

2

To answer your question directly: you must implement a sort of message
passing, so when the UI thread wants to flip/update, it posts a
message for which the video thread waits (for example via
SDL_WaitEvent) and executes. If you’re using something like C++, you
can also make your life easier by using delayed execution of functors,
rather than a standard message queue.

However, I would argue that a better approach is to unify your
graphics code. Do it all in one thread, something like:
for(;:wink: {
SDL_Event event;
while(SDL_PollEvent(&event)) dispatch(event);
drawUI();
drawMainVideo();
for(int i = 0; i < numTimers; ++i) timerTick(timers[i]);
}

(adjust for OOP-style, adaptive framerate, etc as needed)

Hope this helps,
Stefan

3

My application has one fast video thread (updating at 33 ms) using the top
part of the screen, and a slow UI thread (using the bottom of the screen).
If the user hits a button, then some response is required within the UI area
of the screen. The UI has no effect on the video, and the two threads work
on mutually exclusive areas of the screen.

Based on the feedback, I’m considering two approaches:
Approach 1:
When an event happens, the UI thread (i) refreshes screen, (ii) flips
screen, (iii) refreshes screen. This ensures that both screen buffers are
updated. The video thread simply refreshes and flips every 33 ms.

Approach 2:
The video thread updates video AND Ui every 33 ms.

Is one better than the other?

Thanks,
–Shree

4

Why not trying both and see by yourself, it’ll be more didactic than any of our answers, given that the issues have been clarified already. Don’t forget to test on different OS’s if possible.

Regards,

Julien

— En date de?: Mer 10.6.09, shree 0987 a ?crit?:de: shree 0987
Objet: Re: [SDL] Two threads updating screen
?: “sdl at lists.libsdl.org”
Date: Mercredi 10 Juin 2009, 9h54

My application has one fast video thread (updating at 33 ms) using the top part of the screen, and a slow UI thread (using the bottom of the screen).? If the user hits a button, then some response is required within the UI area of the screen. The UI has no effect on the video, and the two threads work on mutually exclusive areas of the screen.

?
Based on the feedback, I’m considering two approaches:
Approach 1:
When an event happens, the UI thread (i) refreshes screen, (ii) flips screen, (iii) refreshes screen. This ensures that both screen buffers are updated. The video thread simply refreshes and flips every 33 ms.

?
Approach 2:
The video thread updates video AND Ui every 33 ms.
?
Is one better than the other?
?
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

5

hi,

You could easily have a back buffer for the UI thread. Then update
all the parts from the video thread.

Update the UI backbuffer Surface to the screen from the video thread.

That’s how I make use of multiple threads/processes for blitting. You
can split the screen up into multiple sections that way.

Another trick is to do separate layers in separate threads(if you use
layers)… but still only update the screen from the main thread.

Note that you’ll probably want to use ncpu-2 threads for the other
sections… as you have one main thread, and one OS thread. eg with
an X server the X server uses a separate cpu/thread already. Runtime
benchmarking is always useful of course (especially with hyper
threading coming back with the latest intel cpus and telling you you
have fake cores/cpus).

cu,On Wed, Jun 10, 2009 at 5:54 PM, shree 0987 wrote:

My application has one fast video thread (updating at 33 ms) using the top
part of the screen, and a slow UI thread (using the bottom of the screen).
If the user hits a button, then some response is required within the UI area
of the screen. The UI has no effect on the video, and the two threads work
on mutually exclusive areas of the screen.

Based on the feedback, I’m considering two approaches:
Approach 1:
When an event happens, the UI thread (i) refreshes screen, (ii) flips
screen, (iii) refreshes screen. This ensures that both screen buffers are
updated. The video thread simply refreshes and flips every 33 ms.

Approach 2:
The video thread updates video AND Ui every 33 ms.

Is one better than the other?

Thanks,
–Shree

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

6

shree 0987 wrote:

My application has one fast video thread (updating at 33 ms) using the
top part of the screen, and a slow UI thread (using the bottom of the
screen). If the user hits a button, then some response is required
within the UI area of the screen. The UI has no effect on the video, and
the two threads work on mutually exclusive areas of the screen.

Based on the feedback, I’m considering two approaches:
Approach 1:
When an event happens, the UI thread (i) refreshes screen, (ii) flips
screen, (iii) refreshes screen. This ensures that both screen buffers
are updated. The video thread simply refreshes and flips every 33 ms.

Approach 2:
The video thread updates video AND Ui every 33 ms.

Is one better than the other?

Thanks,
–Shree

What kind of application are you writing? Will you get screen updates at
or above 33FPS? Why 33FPS? Why not VSYNC?

Do you have performance problems getting 33FPS on your target hardware?
What is your target hardware? What’s the overhead of doing a thread
switch? Why threading at all?

Eddy