Messages

1

General / Using sf::Texture::loadFromFile in a seperate thread.

« on: April 19, 2025, 11:24:36 pm »

Hello everyone,

I'm currently creating a simple project (guess maybe you could call it an engine), for my personal use, that i could reuse in my future applications. So i have thought, that it's a perfect time to start learning some multithreading, and to make the whole project thread-safe.

While working on this, i am using ChatGPT for help.

Basically, Chat has told me, that OpenGL functions that SFML calls internally are not thread-safe, and that loading a sf::Texture object from file is not thread safe also, and loading it, in a separate thread, might cause undefined behavior - because of calls to the OpenGL functions and context switching.

In some of my previous projects i had already used separate thread for loading textures from file, while having a loading screen. I have never had any problems with it, and the loading has succeeded every time (but i have never tested it outside my PC).

The Chat, has also proposed to me a solution to this - he said, that i should load a sf::Image object from file in a separate thread, but then, in a main thread use loadTextureFromImage - in his opinion it would fix this problem.

I'm not sure i can always trust chat with this - especially since i have never had such a problem.

So my question is, is A.I. right about that?
Should i not use a separate thread that loads textures, is it unsafe?
If so, then what are other limitations of multithreading in SFML that i should be aware of?
Is Chat's potential fix to the problem good?

While browsing SFML's texture code on the GitHub, i have found a comment, that says:
"Force an OpenGL flush, so that the texture will appear updated in all context immediately (solves problems in multi-threaded apps)"

I have never encountered an issue with this approach, but I'm concerned that it might not work universally, and since i have not encountered any reproducible errors i don't have any example code to share.


Thanks in advance for you help and advice!

2

Graphics / No more default constructor for sf::Sprite?

« on: February 05, 2025, 07:12:27 pm »

Hello everyone,

I’ve recently started working with SFML 3.0 and I’m facing an issue with the removal of the default constructor for sf::Sprite. In SFML 3.0, sf::Sprite now requires a texture to be passed during construction, which is a change from previous versions where the texture could be set later.

The main reason for my concern is that I prefer to initialize sprites without a texture initially and then assign a texture in a separate function, especially when the texture might not be loaded yet. This approach worked fine in SFML 2.x but is no longer possible in SFML 3.0.

While I can work around this by using lazy initialization (e.g., through std::unique_ptr), this feels cumbersome and inefficient for every sprite. The overhead of managing a unique_ptr just to allow lazy texture assignment doesn't seem ideal. Alternatively, using a placeholder texture works, but it feels like a less clean solution, as it can result in incorrect rendering if forgotten.

I’m curious if there are any other potential workarounds, and I’d appreciate suggestions from anyone who’s dealt with similar challenges.

Thanks!