Memory Management by loadfrommemory

[Laurent]

Is memory growing every time you press '5', or is it growing constantly?

[etixpp]

everytime i press 5, if i put the stuff in the main function without thread i can press 5 untill my finger breaks and it stays at the same allocated memory.

RenderThread.launch() in on(5) -> i can go to 8 gb ram without any problems
funcclass.gogo()  on (5) (Whats exactly what gets executed in the thread) -> i stay at 32600k

[Laurent]

Whenever you're dealing with graphics in a new thread, SFML needs to create a new OpenGL context. And unfortunately it can't destroy it when the thread terminates, since it doesn't know when it happens. So OpenGL contexts accumulate endlessly every time you create a new thread. This is usually not an issue, since threads are not meant to be created / destroyed so many times; it's always better to reuse a thread that always runs in background.

You can try to instanciate a sf::Context yourself at the beginning of the thread function, but I'm not 100% sure it would solve the problem.

[wintertime]

Couldn't that internal context get destroyed with the sf::Window/RenderWindow/RenderTexture/Context? I mean if someone uses stuff without having such an object its user fault and the library could be allowed to not do anything or crash. That would prevent this memory leak and alert the user of his buggy code.
Or you could maybe put some code into sf::Thread that wraps the thread-function and cleans up after it returns, but that would be a gamble and only slightly less messy than always having the leak.

[Laurent]

Couldn't that internal context get destroyed with the sf::Window/RenderWindow/RenderTexture/Context?

What do you mean? There's no relation between the internal context and other contexts.

Or you could maybe put some code into sf::Thread that wraps the thread-function and cleans up after it returns

That wouldn't work with other ways of launching a thread. And since we now have std::thread, sf::Thread tends to get deprecated.

[etixpp]

So if the thread would have a internal while / game loop with own frameset with sf::Time and never end, it should work, right?
Edit: i tried to do it with sf context (Well i just created such a object at the top of the function, did not seem to work, so i tried some stuff like set active true and so on, did not change something aswell, maybe i did something wrong), does not seem to help.

[Laurent]

Yes, that would solve the memory leak problem.

[etixpp]

Allright, big thanks, just tried it out and noticed it works fine, only problem:
The Cpu goes up to 24 when i let the thread non stop running, i already tried to make him as lightly as possible with sf::clock only doing something if 1 second is done and restart the clock.

I think the Windows Sleep() function should send only the internal thread to sleep and let the main function continue if i call it inside the thread(or am i wrong?) but i would like not to use Windows.h stuff if its not absolutly necesary :/

[eXpl0it3r]

Make the current thread sleep for a given duration.

If you don't give resources back the thread will try to run as fast as possible.

[wintertime]

Couldn't that internal context get destroyed with the sf::Window/RenderWindow/RenderTexture/Context?

What do you mean? There's no relation between the internal context and other contexts.

I was assuming that internal per-thread context was only there for hiding problems from people using library objects without creating a context first. If its just for needing an unused context to allow SFML to use ShareLists/CopyContext or similar window system calls, I would think a single hidden context per program and not per thread would be enough?

[etixpp]

Make the current thread sleep for a given duration.

If you don't give resources back the thread will try to run as fast as possible.

Ah, forgot there is a sf::sleep function, thanks! I think topic can be closed now^^

[Laurent]

I was assuming that internal per-thread context was only there for hiding problems from people using library objects without creating a context first

Yes.

If its just for needing an unused context to allow SFML to use ShareLists/CopyContext or similar window system calls, I would think a single hidden context per program and not per thread would be enough?

Since I don't know when the thread terminates, I can't unbind the context from it, and thus I can't reactivate it in another thread. So I need a new context in each thread.

I admit that this is really badly designed (but at least from user point of view things are super easy). I'll probably try to clean it up one day.

[wintertime]

This is confusing me a bit. I thought the documentation said users have to always create a Context or equivalent object manually first to prevent the library from malfunctioning? Wouldn't it then be enough to use a single mutex-protected hidden context just for that moment when the creation for that user Context happens?

[Laurent]

I thought the documentation said users have to always create a Context or equivalent object manually first to prevent the library from malfunctioning?

Please show me where the documentation says that

[wintertime]

Ah sorry, it must have been cause of me reading http://sfml-dev.org/tutorials/2.1/window-opengl.php some days ago and misremembering the text at "OpenGL without a Window" to apply more broadly than there is actually said.