leak ram

[valerion]

sorry for my endlish...
At first it was so

(click to show/hide)

#include "SFML\Graphics.hpp"
#ifndef MAIN_H
#define MAIN_H
 
using namespace std;
 
class Main
{
private:
    sf::CircleShape* shape1, *shape2;
    sf::ContextSettings* settings;
    sf::Clock* clock;
    sf::RenderWindow* window;
    sf::Event* evt;
    sf::Mutex* mut;
    sf::Thread* drawThread;
    float time;
 
public:
    Main();
    void PlayMain();
    void THREAD_Draw();
};
#endif

(click to show/hide)

#include "main.h"
 
Main::Main()
{
    clock = new sf::Clock;
    settings = new sf::ContextSettings(16, 24, 2, 0, 8);
    window = new sf::RenderWindow(sf::VideoMode(800, 600), "SFML works!", sf::Style::Close, *settings);
    mut = new sf::Mutex;
    drawThread = new sf::Thread(&Main::THREAD_Draw, this);
    evt = new sf::Event;
 
    shape1 = new sf::CircleShape(100);
    shape2 = new sf::CircleShape(100);
 
    shape1->setFillColor(sf::Color::Green);
    shape2->setFillColor(sf::Color::Red);
    shape1->setPosition(100, 0);
    shape2->setPosition(300, 0);
 
    time = 0;
    PlayMain();
}
 
void Main::PlayMain()
{
 
    while (window->isOpen())
    {
        time = (float)clock->getElapsedTime().asMicroseconds() / 800;
        clock->restart();
 
        while (window->pollEvent(*evt))
        {
            if (evt->type == sf::Event::Closed)
                window->close();
        }
 
        window->clear();
        window->setActive(false);
 
        drawThread->launch(); drawThread->wait();
 
        window->display();
    }
}
 
void Main::THREAD_Draw()
{
    //mut->lock();
    window->draw(*shape1);
    window->draw(*shape2);
    //mut->unlock();
}

screen 1: "Failed to activate the window's context"

after correction:

void Main::THREAD_Draw()
void Main::THREAD_Draw()
{
        window->draw(*shape1);
        window->draw(*shape2);
        window->setActive(false);
}

it was like on screen 2: leak RAM

[Jesper Juhl]

Don't use raw owning pointers. Use std::unique_ptr (or std::shared_ptr) for owning pointers. Only use raw pointers for observing non-owning pointers.
Also look up RAII.

[eXpl0it3r]

And don't use threads. Whatever you think you'd gain, you think wrong.

Are you coming from a Java or C# background, because as Jesper Juhl said, you should use RAII.

[valerion]

Don't use raw owning pointers. Use std::unique_ptr (or std::shared_ptr) for owning pointers. Only use raw pointers for observing non-owning pointers.
Also look up RAII.

this code is not my, if use shared_ptr problem remains. I agree with you, but problem not in it

[valerion]

And don't use threads. Whatever you think you'd gain, you think wrong.

Are you coming from a Java or C# background, because as Jesper Juhl said, you should use RAII.

then i used thread in training purposes

[Nexus]

this code is not my, if use shared_ptr problem remains.

The idea is not to use shared pointers. Use pure objects wherever possible, not pointers.

I agree with you, but problem not in it

You talk about memory leaks and show a code that blatantly provokes them... So this is hard to believe.

If you're sure that the problem persists, then show the new code. If you write it correctly, the code won't contain a single new keyword.

By the way, to detect memory leaks, you should use a tool designed for that task, not the Windows task manager.

[valerion]

this code is not my, if use shared_ptr problem remains.

The idea is not to use shared pointers. Use pure objects wherever possible, not pointers.

I agree with you, but problem not in it

You talk about memory leaks and show a code that blatantly provokes them... So this is hard to believe.

If you're sure that the problem persists, then show the new code. If you write it correctly, the code won't contain a single new keyword.

By the way, to detect memory leaks, you should use a tool designed for that task, not the Windows task manager.

tool, for example?

[valerion]

new code without pointers
main.h

(click to show/hide)

class Main
{
private:
        sf::CircleShape shape1, shape2;
        sf::ContextSettings settings;
        sf::Clock clock;
        sf::RenderWindow window;
        sf::Event evt;
        sf::Mutex mut;
        float time;

public:
        Main();
        void PlayMain();
        void THREAD_Draw();
};

main.cpp

(click to show/hide)

#include "main.h"

Main::Main()
{
        window.create(sf::VideoMode(800, 600), "SFML works!", sf::Style::Close, settings);

        shape1.setRadius(100);
        shape2.setRadius(100);
        shape1.setFillColor(sf::Color::Green);
        shape2.setFillColor(sf::Color::Red);
        shape1.setPosition(100, 0);
        shape2.setPosition(300, 0);

        time = 0;
        PlayMain();
}

void Main::PlayMain()
{
        sf::Thread drawThread(&Main::THREAD_Draw, this);
        while (window.isOpen())
        {
                time = (float)clock.getElapsedTime().asMicroseconds() / 800;
                clock.restart();

                while (window.pollEvent(evt))
                {
                        if (evt.type == sf::Event::Closed)
                                window.close();
                }

                window.clear();
                window.setActive(false);

                drawThread.launch();
                drawThread.wait();

                window.display();
        }
}

void Main::THREAD_Draw()
{
        //mut->lock();
        window.draw(shape1);
        window.draw(shape2);
        window.setActive(false);
        //mut->unlock();
}

old problem remains

[valerion]

on one forume i got this answer:
Problem is that when creating in thread, creates a hidden context opengl and added to "global basked"(std::set <GlContext*> internalContext) and at destruction thread isn`t released.

[zsbzsb]

Yes it is true that SFML will create a context on every thread that you use to preform graphics operations. The solution to fix this is to simply reuse the same thread.

Now it is also true that you do not understand how threads work and when to use them. When you launch a new thread every frame and then block the main thread until that other thread finishes you gain absolutely none, zero, zip performance from your code. In fact you will actually hurt the performance of your code as all you do is simply add more overhead (creating, launching, switching threads is expensive operations).

The purpose of threads is to execute code in parallel, but if you aren't even running code in parallel you are just adding unnecessary overhead to your code for no reason. Oh, and once you actually get code running in parallel you need to learn how to protect memory so it doesn't access memory that another thread is using. That in itself is a huge topic and has many pitfalls (even if you execute code in parallel you may lose performance because of memory protection).

What you should do is forget you even heard of multithreading and make your entire program single threaded. Once you actually have a finished program use a profiler to see where your actual bottlenecks lie and then optimize that code (it probably won't even involve threads).

[valerion]

The solution to fix this is to simply reuse the same thread.

Bad solution. If i use a lot of draw function and other function, work with lists, in main thread, all this very loaded and becomes visible small hang. Solution was to divide all of different thread.

[zsbzsb]

Bad solution. If i use a lot of draw function and other function, work with lists, in main thread, all this very loaded and becomes visible small hang. Solution was to divide all of different thread.

Read my reply again and again until you understand it. Launching a new thread and then blocking until it is finished every single frame will not get you anymore performance (this does not matter if you are using SFML or anything else). It isn't even how you are supposed to use threads. And as for reusing a thread, its the only solution to prevent SFML from creating a new context per thread.

[Gambit]

The solution to fix this is to simply reuse the same thread.

Bad solution. If i use a lot of draw function and other function, work with lists, in main thread, all this very loaded and becomes visible small hang. Solution was to divide all of different thread.

If your application is lagging when you are trying to draw a lot of stuff you should probably consider trying to reduce the amount of draw calls you are making. As for the threads, it has been said more than once that you are getting absolutely 0 benefit from using them considering you are using them incorrectly. I also dont believe that the threads you are using are actually making your program run any faster but instead are "masking" your problem and making it seem like its working.

[mkalex777]

Completely agree, using multithreaded game loop is very complicated solution and you need to understand all details about thread synchronization, thread context switch, how works system scheduler, what is time slice, how to switch windows to realtime mode and why it gives faster respose time, but slower performance and many other things.
Single threaded game loop is very simple and gives you a lot of benefits in performance. So, you are need for a very significant reason to use multithreading, becuse you will loss ability to use simple and fast code and your code will be complicated.