I create 2 windows in separate threads. They create just fine. Each window shows its first rendered content.
First window:
Code:
creates
renders first screen
will take input until you click on second window then first window no longer responds to input and stops updating screen when window selected.
Second window:
Code:
creates
renders first screen
does not respond to any input and does not update screen when window selected.
Every once in a while I will see this:
Code:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 458 requests (458 known processed) with 0 events remaining.
Does anyone have an example of working multiple windows?
Its wrong to create windows in other threads than the main oneOn Fri, Jun 17, 2011 at 7:27 PM, greno wrote:
**
I’m using SDL 1.3 on Linux.
I create 2 windows in separate threads. They create just fine. Each window
shows its first rendered content.
First window:
Code:
creates
renders first screen
will take input until you click on second window then first window no
longer responds to input and stops updating screen when window selected.
Second window:
Code:
creates
renders first screen
does not respond to any input and does not update screen when window
selected.
Every once in a while I will see this:
Code:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server
":0.0"
after 458 requests (458 known processed) with 0 events remaining.
Does anyone have an example of working multiple windows?
Ok, I thought that SDL 1.3 supported multiple windows and threading.
If I just use one thread to create its window everything works great.
And when I use two threads the windows create just fine but they don’t respond correctly.
So is the SDL library not thread-safe?
And if I were to go and create all the windows ahead of time in the main thread and then pass window handles into each thread would this work any better?
SDL supports multiple window creation, but they have to all be on the same thread.? That shouldn’t be a problem.________________________________
From: greno@verizon.net (greno)
Subject: Re: [SDL] SDL 1.3: Multiple Windows
Ok, I thought that SDL 1.3 supported multiple windows and threading.
If I just use one thread to create its window everything works great.
And when I use two threads the windows create just fine but they don’t respond correctly.
So is the SDL library not thread-safe?
And if I were to go and create all the windows ahead of time in the main thread and then pass window handles into each thread would this work any better?
First exaplin what you want to do.So we can give you solutions on what
you have in mindOn Fri, Jun 17, 2011 at 9:54 PM, greno wrote:
Ok, I thought that SDL 1.3 supported multiple windows and threading.
If I just use one thread to create its window everything works great.
And when I use two threads the windows create just fine but they don’t
respond correctly.
So is the SDL library not thread-safe?
And if I were to go and create all the windows ahead of time in the main
thread and then pass window handles into each thread would this work any
better?
Basicly you should have in mind that everything regarding rendering
(Windows,Textures, Renderer’s) have to be on the main thread.On Fri, Jun 17, 2011 at 10:05 PM, Mason Wheeler wrote:
Why are you conflating threads and windows?
SDL supports multiple window creation, but they have to all be on the same
thread.? That shouldn’t be a problem.
From: greno
Subject: Re: [SDL] SDL 1.3: Multiple Windows
Ok, I thought that SDL 1.3 supported multiple windows and threading.
If I just use one thread to create its window everything works great.
And when I use two threads the windows create just fine but they don’t
respond correctly.
So is the SDL library not thread-safe?
And if I were to go and create all the windows ahead of time in the main
thread and then pass window handles into each thread would this work any
better?
I think is more than just window creation since at one point you would
want to draw something on screen.Drawing can be done only in the main
threadOn Fri, Jun 17, 2011 at 10:25 PM, greno wrote:
This is an app that requests and receives remote data from multiple network
sources and displays it in near realtime in multiple windows.
Each thread handles its own independent data source.
So should I create all the windows ahead of time and just pass the window
handles into the threads? Or is it more than just window creation?
I recommend that each thread gets a threadsafe queue that it shares with the
main thread, so the incoming information can be drawn safely on the
individual windows.On Fri, Jun 17, 2011 at 3:33 PM, Dimitris Zenios <dimitris.zenios at gmail.com>wrote:
I think is more than just window creation since at one point you would
want to draw something on screen.Drawing can be done only in the main
thread
On Fri, Jun 17, 2011 at 10:25 PM, greno wrote:
This is an app that requests and receives remote data from multiple
network
sources and displays it in near realtime in multiple windows.
Each thread handles its own independent data source.
So should I create all the windows ahead of time and just pass the window
handles into the threads? Or is it more than just window creation?
Thats a nice solution.You push the events from the threads to a queue
in the main thread and you process them from thereOn Fri, Jun 17, 2011 at 10:36 PM, Alex Barry <alex.barry at gmail.com> wrote:
I recommend that each thread gets a threadsafe queue that it shares with the
main thread, so the incoming information can be drawn safely on the
individual windows.
On Fri, Jun 17, 2011 at 3:33 PM, Dimitris Zenios <@Dimitris_Zenios> wrote:
I think is more than just window creation since at one point you would
want to draw something on screen.Drawing can be done only in the main
thread
On Fri, Jun 17, 2011 at 10:25 PM, greno wrote:
This is an app that requests and receives remote data from multiple
network
sources and displays it in near realtime in multiple windows.
Each thread handles its own independent data source.
So should I create all the windows ahead of time and just pass the
window
handles into the threads? Or is it more than just window creation?
You cannot do any rendering from other threads than the main one.You
have to pass the data from the threads to the main queue in the main
thread and do the rendering from the main threadOn Fri, Jun 17, 2011 at 10:51 PM, greno wrote:
Yes, I have a queue already for the threads to pass certain data. This
works.
I want the threads to handle the streaming updates. Can I render these from
the threads?
I wouldn’t recommend sharing a pointer unless you can guarantee that the
thread will not change the address, and that the variable will not leave the
scope for any reason (a loop, most likely). Copying the data would be
safer.On Fri, Jun 17, 2011 at 3:59 PM, greno wrote:
**
So I can preprocess the data in the thread and then push a pointer to the
data on the shared queue.
And what is best way to signal main thread to render the data? Just have it
polling the queue? Or have it wait on a signal?
You should make some tests with a central, thread-safe queue receiving the data from the various sources, and see if the response time is satisfying for your needs.
Each data is collected from each data thread and pushed on the central queue, and then dispatched to the appropriate windows.
If the data you are displaying are not interrelated, you can also consider launching multiple processes instead of multiple thread, each process having its own execution context and data, based on SDL 1.3. This way you can benefit from parallelism and avoid complex drawbacks linked with drawing and multi-threading.
If your data are interrelated and you need a high response time, and if 1) didn’t get you satisfied, think about switching to another more appropriate tool/lib.
Let us know
Best,
Julien CLEMENT
@Julien_Clement1> Date: Fri, 17 Jun 2011 12:51:47 -0700
From: “greno”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3: Multiple Windows
The data is very large. Copying would slow things down quite a bit.
I think we can guarantee the integrity of the pointer by having the main thread pass back an indicator that it is through with the pointer. Probably just by setting it NULL.
Message-ID: <1308340307.m2f.29120 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
Yes, I have a queue already for the threads to pass certain data. ?This works.
I want the threads to handle the streaming updates. ?Can I render these from the threads?
Technically you can try, but honestly you can’t. It isn’t a problem
with SDL, it’s a problem with the Operating Systems.
Apple doesn’t support rendering from anything but the main thread: if
you try, then it apparently pauses the thread making the attempt until
the main thread can do it; Windows can do it, but the window can only
be rendered from the thread that created it (but it doesn’t matter,
since you should try to be platform-agnostic with SDL’s features); I
thought that XWindows could handle it, due to the fact that it
transports the render commands over an inter-process communications
channel, but it doesn’t matter, since you should try to be
platform-agnostic with SDL’s features.
In short, only deal with windows and renderers in the main thread.
Processing that doesn’t use the wiundowing/rendering support should be
perfectly fine.> Date: Fri, 17 Jun 2011 12:51:47 -0700
From: “greno”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3: Multiple Windows
I had a similar problem where I had a program listening to several
different sockets (each in it’s on thread). When the threads received
data, they processed it and pushed an event onto the SDL event queue
using SDL_PushEvent.
my event queue then had special processing for SDL_USEREVENT. The code
below shows part of the queue implementation for receiving timer ticks
that originated over the network.
while (SDL_WaitEvent(&event))
{
switch (event.type) {
...
case SDL_USEREVENT:
if (event.user.code == Timer::TIMER_TICK_EVENT) {
ctrl->getTimer()->tickTock();
}
...
break;
}
...
}
Hope that helps,
JohnOn Sat, Jun 18, 2011 at 4:13 AM, Jared Maddox wrote:
Date: Fri, 17 Jun 2011 12:51:47 -0700
From: “greno”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3: Multiple Windows
Message-ID: <1308340307.m2f.29120 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
Yes, I have a queue already for the threads to pass certain data. ?This works.
I want the threads to handle the streaming updates. ?Can I render these from the threads?
Technically you can try, but honestly you can’t. It isn’t a problem
with SDL, it’s a problem with the Operating Systems.
Apple doesn’t support rendering from anything but the main thread: if
you try, then it apparently pauses the thread making the attempt until
the main thread can do it; Windows can do it, but the window can only
be rendered from the thread that created it (but it doesn’t matter,
since you should try to be platform-agnostic with SDL’s features); I
thought that XWindows could handle it, due to the fact that it
transports the render commands over an inter-process communications
channel, but it doesn’t matter, since you should try to be
platform-agnostic with SDL’s features.
In short, only deal with windows and renderers in the main thread.
Processing that doesn’t use the wiundowing/rendering support should be
perfectly fine.