Messages

31

System / Drawing from within a thread

« on: January 02, 2009, 01:15:50 pm »

I found and interesting note on multithreading in Microsoft's documentation to wglmakecurrent:
http://msdn.microsoft.com/en-us/library/ms537558(VS.85).aspx

There they say that one can/should use a separate device and rendering context per thread. I don't know much about OpenGL, but I wonder if is possible to display more than one context at a time.

By the way: Both the documentation of wglMakeCurrent and glXMakeCurrent state that the rendering context of the calling thread is changed, which implies that the function knows which thread it called.
When I posted my question here yesterday, I thought this might be a problem, but I simply didn't think of the possibility that a thread library will likely offer a function to retrieve the current thread's id. As the OpenGL calls are performed in the context of the calling thread, it shouldn't be a problem to find out which thread it called.

Oh, and I hope you didn't misunderstand my previous posting: A strict alternation of function calls alone didn't work, I had to make the window active/inactive each time in the appropriate thread. I slowly start to believe that it is really something thread-specific and not only parallelism-specific

32

System / Drawing from within a thread

« on: January 02, 2009, 02:22:30 am »

Really strange.

I just tried to add some mutual exclusion to my program, and indeed, it only works correctly if I make one window inactive and the other active. But it's the same window in both cases!

I'd really like to understand what happens here. I found lots of threads saying OpenGL is not thread-safe, but even in that case, a strict alternation of the draw operations should be sufficient in my opinion - but obviously, this isn't the case.

Anyway, I now just draw the stars within my main loop and not within a separate thread.

33

System / Drawing from within a thread

« on: January 01, 2009, 09:22:43 pm »

How does/can OpenGL know that a context is active within multiple threads?

It doesn't have to know this, you just can't activate a context if it's already active in another thread

And why is it/must it be activated from within the second thread?
I still have some problems in understanding the  difference between:

Code: [Select]


Thread A:
Create/Init Window
DrawSomeObject
DrawAnotherObject

and

Code: [Select]


Thread A:                             Thread B:
Create/Init Window
DrawSomeObject
                                      DrawAnotherObject


Both examples should result in the same sequence of OpenGL function calls, shouldn't they? (assuming that DrawSomeObject and DrawAnotherObject don't run in parallel).

34

System / Drawing from within a thread

« on: January 01, 2009, 09:04:35 pm »

The problem is that OpenGL (and thus SFML) doesn't allow a context (RenderWindow) to be active in multiple threads at the same time.

So you can actually draw from many threads, but you have to :
- Activate the window (window.SetActive(true))
- Do your drawing
- Deactivate the window (window.SetActive(false))

And make sure that no thread will try to do the same stuff at the same time.

You should get error messages accordingly, saying something like "the operation is not allowed in the current state".

Thanks for the answer. To ensure that no two threads set the same window active/inactive concurrently, I'd have to use some mutex or lock, I guess. In that case, using a thread won't probably be very advantageous compared to the single-threaded solution.

By the way: How does/can OpenGL know that a context is active within multiple threads?
Supposed we have a thread A that tries to draw something, and another thread B that tries to draw something else.
If the two calls would strictly alternate (i.e., never occur concurrently), wouldn't it look to OpenGL as if both calls were made from within the same thread, one after the other?

35

System / Drawing from within a thread

« on: January 01, 2009, 08:08:18 pm »

Now I modified my program a bit so that no drawing is performed within the main loop, but only from within the thread (the main loop only does the event handling).

This didn't improve the situation, now I only see lots of garbage within the window, as if it wasn't correctly initialized. Really weird.

EDIT: I just found this thread here:
http://www.sfml-dev.org/forum/viewtopic.php?t=349

I guess that's more or less the same problem I encounter here, isn't it?
Should I see any error messages in that case?

36

System / Drawing from within a thread

« on: January 01, 2009, 07:41:15 pm »

As explained in my other posting here, I have written a small class that inherits from the thread class.
The purpose of this thread is to draw some moving stars (up to now, these are only small, white rectangles). This starfield class has a member variable that points to the appropriate RenderWindow.

The class's Run() method calls another method that iterates over all the stars, creates a Rectangle for each, and draws this Rectangle to the RenderWindow that is specified by the appropriate pointer.

The Display()-method of the RenderWindow is called outside this thread, in the program's main loop.

Now, for some reason, whatever I try to draw within this separate thread doesn't get displayed on the window, whereas stuff I draw in the main loop is correctly displayed.

In contrast, when I call the Draw-method of my Starfiled class from within the main loop, everything is displayed correctly.

Is this some sort of race condition, as it might happen that the thread tries to draw some stuff on the RenderWindow, while the main loop calls Display()?
If so, I guess I'd have to use some mutex for synchronization, but in that case, there wouldn't be any benefit from using a separate thread for drawing those stars (my original intention was to keep movement of the player's sprite more responsive, by not having to wait until all stars are drawn before input is processed).

37

System / Correct method for thread termination?

« on: January 01, 2009, 03:22:03 pm »

Hi all, and happy new year

I have a small question regarding threads: I have written a class that inherits from the thread class, let's call it "Mythread". The according thread does nothing but to draw some pixels on the screen all the time (which currently doesn't work, but that's another problem ).

When my main application is about to terminate, this thread should of course also end. My current implementation of this looks (roughly) as follows:

Code: [Select]


void Mythread::Run()
{
    while ( this->running )
    {
        // call method to draw something
    }
}

void Mythread::~Mythread()
{
    this->running = false;
    this->Wait();

    // call delete for other Mythread-intenal stuff
}


So my main application does nothing but to call the destructor of the Mythread class when it's about to exit.

I have included some debugging output in the functions shown above, and from what I can see there, this solution seems to work correclty. Anyway, I thought to better ask here if it really is correct or if something is wrong with it.

By the way: While testing this stuff, I made my Linux crash twice. Probably, my mistake was to call Mainwindow.Close() before exiting the thread. So it could have happended that the thread tried to draw to a non-existing window. This, of course, shouldn't lead to a system crash, but there seems to be some bug within the ATI video driver.
The syslog says:
BUG: unable to handle kernel paging request at 0000100000002068
IP: [<ffffffffa022b8d5>] firegl_unlock+0xb5/0x1b0 [fglrx]

I don't know if this could be worked around within the SFML, but as I find this bug rather interesting, I thought I'd post it here

38

General / Mac OS X installation

« on: March 24, 2008, 07:06:08 pm »

Seems as if my build configuration was not completeley successful. While I can compile all the stuff with "Debug" settings, building the "Release" configuration fails with tons of unknown symbols.
I have no idea why, the project settings I made were for both configs.

EDIT: Now, after asking Google, it seems to work. The "Debug" mode seems to have the so-called "ZeroLink" Option enabled by default, which resolves some symbols at runtime.
I had to had Carbon, OpenGL, and IOKit. Additionally, the self-compiled SFML libs also had some problems with unresolved symbols with the Clock class. It works with the pre-compiled libs.

Yet, I am not sure if it was a good idea to only use such a simple console application as basis: All keyboard input seems to go directly to the console instead of the application window.

39

General / Mac OS X installation

« on: March 24, 2008, 05:53:27 pm »

I managed to compile a simple SFML Test application now, but I'm not sure if the way I did it is correct or if there is a simpler way.

AFAIK, it looks good

Please note that the MacOS port is alive again. It will be completely rewritten to use Cocoa instead of Carbon, and all the project files and installation tutorials will be provided
Everything should be ready in a few weeks of months.

That's good news.

So the current Mac OS X implementation uses Carbon, not Cocoa? I'm just wondering why adding the Cocoa Framework to my application made it work. Perhaps I should try if it works with the Carbon Framework instead, too.

40

General / Mac OS X installation

« on: March 24, 2008, 04:15:52 pm »

I'm trying to get SFML working under OS X (10.4), too. I managed to compile a simple SFML Test application now, but I'm not sure if the way I did it is correct or if there is a simpler way.

What I did is the following:
1. I downloaded and extracted the SDK and then copied it to a suitable location (e.g. ~/Programming/SFML).
2. I opened the Xcode projects found in the xcode subfolder and built them. This creates libraries for all the parts of SFML (Windowing, Graphics, and so on).
3. I created a new project in Xcode, a simple C++ Console Utility or however this is called. This creates only a minimal project with a "main.cpp"
4. I the project settings, I added the include-directory within the SFML directory both to "Header Search Paths" and "User Header Search Path". I think the former would have been sufficient, but I tried the latter (i.e. the user path) first, and that alone didn't work.
5. I added the self-compiled SFML-libraries to the Xcode Project (Choosing Project -> Add to project)
6. Finally, I added both the AGL and the Cocoa Framework in the same way. Both frameworks can be found in /System/Library/Frameworks.

I'm not sure if all that stuff works with 10.5. In another thread, someone wrote that he was not able to compile the Xcode projects that come along with the SDK. In that case, you might try to add the libraries that can be found in the "lib" subdir within the SFML folder instead of the self-compiled ones.