[SOLVED] Thread acting differently than in SDL

[jValdron]

Hello from Canada! (French Canadian, but nope not a "Quebecois")

I'm new to SFML, as of today. I'm porting my SDL application to SFML 1.6 for performance reasons. A simple 1080p video is rendering about 4x faster in SFML.

So, I got a problem with my threads... I'm not really an expert with C++ nor an expert with multi-threading.

The problem is that I create and launch a thread in the constructor of one of my classes, but my main loop (in which the object is created, hence the constructor called), doesn't display the RenderWindow until the thread is finished. Which is the reason I want to have threads.

So here is an example of my situation (not the exact code, but you'll understand):

main.cpp

Code: [Select]


new Scene();

while(App->IsRunning())
{
    ... my render stuff, that only starts after the thread is terminated (so after the FadeInThread method is done) ...    
}


Scene.cpp

Code: [Select]


Scene::Scene(sf::RenderWindow* Window, float Length)
{
   
    ... some code ...

    this->fadeIn();
   
}

void Scene::FadeIn()
{

    this->Opacity = 0;
    sf::Thread Thread(FadeInWrap, this);
    Thread.Launch();
    // SDL : SDL_CreateThread(FadeInWrap, this);

}

// This is a static method.
void FadeInWrap(void* Scn)
{
    ((Scene*) Scn)->FadeInThread();
}

void Scene::FadeInThread()
{
 
    float Delay = 0.007;
   
    while(this->Opacity < 255)
    {
        this->Opacity++;
        sf::Sleep(Delay);
        // SDL: SDL_Delay(Delay); (Delay was an int calculated differently)
    }
   
}


I know the static to non-static method is kinda weird, but only way I found out in SDL.

There's not much of a difference between a thread in SDL and in SFML, as far as I can see. Just don't understand why it doesn't continue the main execution while performing an operation in a thread.

Basically, if I launch my application, there's a 1.785 second delay because of the FadeInThread.

Could anyone help me out? I'm currently using the SDL_Thread, it works along SFML, but why import and use a huge library when SFML could do that for me.

[Groogy]

Can you reproduce the problem in an minimal example?

From what I can see it looks like you have the window created in one thread but used in another right? Does the creating thread use the window for anything at the same time? Did you remember to activate the window's context in the new thread?

[jValdron]

I don't use the window in the other thread, just modify a variable so that in my main rendering loop, it changes the opacity.

I must be the one that didn't understood something somewhere... but I just create a quick sample of the problem:

main.cpp

Code: [Select]


#include <iostream>
#include <SFML/Graphics.hpp>

 
int Opacity = 255;
bool Running = true;

void FadeInThread(void* Data)
{
 
    float Delay = 0.007;
   
    while(Opacity <= 255)
    {
        std::cout << "Fade is at " << Opacity << std::endl;
        Opacity++;
        sf::Sleep(Delay);
    }
   
    std::cout << "Thread terminated" << std::endl;
   
}

void FadeIn()
{

    Opacity = 0;
    sf::Thread Thread(FadeInThread);
    Thread.Launch();

}

int main()
{
   
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Window");

    // Usually this is a video, or image, or text that I fade in and out
    sf::Image Image(200, 200, sf::Color(0, 255, 0, Opacity));
    sf::Sprite Sprite;
    Sprite.SetImage(Image);
   
    FadeIn();
   
    while(Running)
    {
       
        // Start - Non related event handling stuff
        sf::Event Event;
        while(App.GetEvent(Event))
        {
            if(Event.Type == sf::Event::Closed || (Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
            {
                Running = false;
            }
        }
        // End - Non related event handling stuff
       
        App.Clear();

        // Here I apply the opacity to the image, so that it "fades in"
        Sprite.SetColor(sf::Color(0, 255, 0, Opacity));
        App.Draw(Sprite);
       
        App.Display();
       
    }
   
    return 0;
   
}


[Groogy]

On my phone so can't test it but looks like it should run.

Also threads for this is way overkill! Use the delta time for animations!

[Laurent]

The sf::Thread object has to remain alive as long as the thread function runs. The destructor of sf::Thread calls Wait(). So declaring a sf::Thread instance locally to a function has no effect.

But you definitely don't need a thread for this, you can handle the fading in your main loop.

[jValdron]

Thanks, definitely gives me an insight on how thread works. I did change everything to a delta time like technique. All good now, no more SDL