wxThread and OpengL

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
User avatar
papillon68
Earned some good credits
Earned some good credits
Posts: 118
Joined: Tue Nov 06, 2007 11:19 pm

wxThread and OpengL

Post by papillon68 »

Hello, I am experimenting with the thread sample provided and I ran into an issue that I can't seem to figure out. Basically the creation of an openGL display list executed in the thread entry code is invalid, issuing a generic "invalid OpenGL error 1282".
Here is how I modified the code to test this:

Code: Select all


wxThread::ExitCode MyThread::Entry()
{
	mainFrame->myCanvas->testDL = glGenLists(1);
	glNewList(mainFrame->myCanvas->testDL, GL_COMPILE);
	glPointSize(64);
	glColor3f(1, 0, 0);
	glBegin(GL_POINTS);
	glVertex3f(0, 0, 0);
	glEnd();
	glEndList();
	mainFrame->myCanvas->Refresh();
To note that the display list generates (and display successfully) if I create it for example in the MyThread *MyFrame::CreateThread(int ID) routine.
Any idea of what could be wrong? Thanks
Windows 10, MS VC++ 2019 (vc142), WxWidgets 3.14
Designed with WxWidgets: https://www.facebook.com/clorofillaApp
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxThread and OpengL

Post by ONEEYEMAN »

Hi,
Accessing ANY GUI IN THE SECONDARY THREAD IS NOT SAFE AND WILL LEAD TO CRASJES!!!!

It might work in one OS, or maybe 2 (if you are lucky), but generally in a cross-platform environment it is considered a VERY BAD PRACTICE!!!

Thank you.
User avatar
papillon68
Earned some good credits
Earned some good credits
Posts: 118
Joined: Tue Nov 06, 2007 11:19 pm

Re: wxThread and OpengL

Post by papillon68 »

Right so best course of action is to move to VBO so that I can run threads to prepare and collect vertex data and later l, when threads have ran off, or bind the buffer?
Windows 10, MS VC++ 2019 (vc142), WxWidgets 3.14
Designed with WxWidgets: https://www.facebook.com/clorofillaApp
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxThread and OpengL

Post by ONEEYEMAN »

Depends on the requirements.

Thank you.
Manolo
Can't get richer than this
Can't get richer than this
Posts: 827
Joined: Mon Apr 30, 2012 11:07 pm

Re: wxThread and OpengL

Post by Manolo »

OpenGL was not designed with multithread on sight. Internally the hardware will split the task into several "paths". But externally only a thread can use gl-commands in a current gl-context
So, if you want your thread to execute some gl-stuff then call wxGLCanvas::SetCurrent() or wxGLContext::SetCurrent() from within the thread.
But this is not enough. If thread A calls SetCurrent and start sending gl-commands to the GPU and in the while thread B does the same, then some commands in thread A are sent with a not-current context. Disaster. You must prevent it with some condition/semafore/atomic/whatever way.

A way to avoid the crash is using shared contexts. You set current context 1 from thread A, and shared context 2 from thread B. Good news is that shared context share most data (buffers, textures, etc).

A good advise is to use only one context in one thread (normally the main one). You can have several threads preparing data, and let the main thread to update it to the GPU and use the rest of gl-commands.
User avatar
papillon68
Earned some good credits
Earned some good credits
Posts: 118
Joined: Tue Nov 06, 2007 11:19 pm

Re: wxThread and OpengL

Post by papillon68 »

Manolo wrote:OpenGL was not designed with multithread on sight. Internally the hardware will split the task into several "paths". But externally only a thread can use gl-commands in a current gl-context
So, if you want your thread to execute some gl-stuff then call wxGLCanvas::SetCurrent() or wxGLContext::SetCurrent() from within the thread.
But this is not enough. If thread A calls SetCurrent and start sending gl-commands to the GPU and in the while thread B does the same, then some commands in thread A are sent with a not-current context. Disaster. You must prevent it with some condition/semafore/atomic/whatever way.

A way to avoid the crash is using shared contexts. You set current context 1 from thread A, and shared context 2 from thread B. Good news is that shared context share most data (buffers, textures, etc).

A good advise is to use only one context in one thread (normally the main one). You can have several threads preparing data, and let the main thread to update it to the GPU and use the rest of gl-commands.
Thank you very much for the detailed explanation and suggestion, yes I will go with your last advise, prepare data in the threads and then feed that to the GPU at once from the main thread.
Windows 10, MS VC++ 2019 (vc142), WxWidgets 3.14
Designed with WxWidgets: https://www.facebook.com/clorofillaApp
gtafan
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 201
Joined: Wed Mar 29, 2017 9:52 am

Re: wxThread and OpengL

Post by gtafan »

ONEEYEMAN wrote:Hi,
Accessing ANY GUI IN THE SECONDARY THREAD IS NOT SAFE AND WILL LEAD TO CRASJES!!!!

It might work in one OS, or maybe 2 (if you are lucky), but generally in a cross-platform environment it is considered a VERY BAD PRACTICE!!!

Thank you.
What you mean by NOT SAFE? Not thread safe? Why should it be a bad practice?
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxThread and OpengL

Post by ONEEYEMAN »

Hi,
Yes, I mean not thread-safe.

Thank you.
Post Reply