Creating sf::Texture on another thread

[Vortico]

Hello, I have recently come across a problem when trying to create a sf::Texture on a worker thread and later rendering it to a window on another thread.

All that is required to crash the program is the statement `new sf::Texture` in the worker thread.

On Linux, the main thread crashes when clearing (RenderTexture::clear()) an unrelated RenderTexture:

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
 

On Mac OS X, the program does not crash, but unallocated garbage is displayed instead of the texture created on the worker thread. However, on this platform, I was able to display the texture by calling `texture->copyToImage()` in the worker thread without assigning the return value to anything.

I realize this may not be enough code and information to solve the problem, but I can give the GitHub link to the project if requested. Or, I could be making an obvious mistake, in which these symptoms could hint toward a general solution.

[Laurent]

On Linux, as the error says, you have to call XInitThreads() (from Xlib) to work with more than one thread without errors.

On Mac, I guess you have to call glFlush() (from OpenGL) after the texture is updated in the worker thread.

[Vortico]

Thanks so much. glFlush() works on Mac OS X, and I will test the XInitThreads() call on Linux tomorrow.

However, requiring this seems odd since I only need to create Textures on another thread, not RenderTargets. Is there a pure-SFML method of creating Textures on another thread (to be ultimately rendered by the main thread) or is your recommended solution the best method? I have no problem with the direct OpenGL and Xlib calls, but I was just curious.

[Laurent]

To create a texture in a thread, you need to instianciate an OpenGL context in that thread. And to create an OpenGL context, you need Xlib specific calls. So no, there's really no other way.

But SFML should take care of all this stuff, the suggested extra calls are a workaround. It should be done in a future version.

[Vortico]

Good to hear!
I can confirm that XInitThreads() fixes my problem on Linux.