1
Graphics / Re: Creating sf::Texture on another thread
« on: June 04, 2013, 04:45:15 am »
Good to hear!
I can confirm that XInitThreads() fixes my problem on Linux.
I can confirm that XInitThreads() fixes my problem on Linux.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Graphics / Re: Creating sf::Texture on another thread
« on: June 03, 2013, 04:35:46 am »
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.
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.
3
Graphics / Creating sf::Texture on another thread
« on: June 02, 2013, 10:28:16 pm »
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:
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.
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.
[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.
Pages: [1]