Hi there,
Currently, I am trying to separate the display list from the OnPaint(), but glGenLists(1) return 0.
Is there any prerequisite on using display list?
Is function glGenLists(1) only survive inside OnXxx() event thread?
Thank you!
views:
63answers:
3
+3
A:
The only requirement is having a valid OpenGL context made current. You probably don't have one. If you use multiple threads, you need to use multiple GL contexts which share objects.
Matias Valdenegro
2010-10-26 03:33:48
Thanks for the hints. Perhaps I have to know where to create extra `GL context` and where to `make current` under wxWidgets.
Smile Programming
2010-10-26 04:19:24
Question on `SetCurrent()`, is the background thread necessary to `SetCurrent()`? If yes, the background `SetCurrent()` is racing with `SetCurrent()` inside `OnPaint()`.
Smile Programming
2010-10-26 06:54:15
I assume that SetCurrent makes the context current, then yes, you need to make it current in each thread you want to use it.
Matias Valdenegro
2010-10-26 15:19:38
If I want the primary thread focus on `call list` and the background thread focus on `new list`, the `SetCurrent` looks a bit annoying.
Smile Programming
2010-10-27 01:22:44
And why do you think this is a good idea?
Matias Valdenegro
2010-10-27 02:51:46
Actually, I have few options on the design. The top priority I want to achieve is a non-interrupt UI, and I like to keep the primary thread only `listening to event` and `draw whatever available on display list`. I am now have a shared context, perhaps I can also share the `SetCurrent()` safely. Thank you so much for the idea.
Smile Programming
2010-10-27 03:58:11
No, you can't, a context can be current to only ONE thread.
Matias Valdenegro
2010-10-27 04:43:42
You are right, so I realize I gain no response bonus at last.
Smile Programming
2010-10-27 06:15:06
+1
A:
From what I understand, OpenGL can be used across multiple threads (with some caveats), but you should avoid doing so when possible. glGenLists is probably failing because, as mentioned, you are calling it in a different thread than the one you used to create your OpenGL context. If you can, I would suggest moving something other than OpenGL calls to the second thread.
nonVirtualThunk
2010-10-26 03:51:53
Thanks your suggestion. Because there are huge number of segment to be draw in the `display list`, I would like the `new list` part running in background too.
Smile Programming
2010-10-26 04:16:02
+1
A:
OpenGL and threads do not mix. If you really needs threads, call OpenGL functions only in one threads.
As already said, the glGenLists returns 0 on errors. Check the error with glGetError function.
VJo
2010-10-26 09:49:05
Thanks. Is that means `call list` and `new list` cannot separate ideally?
Smile Programming
2010-10-27 01:25:56
Both you and @nonVirtualThunk has the point, I found not much gain from separating GL calls.
Smile Programming
2010-10-27 04:24:02
If you want to separate in threads, then no. What are you doing? There might be other ways
VJo
2010-10-27 05:52:20
Originally, I have a container which carry all the `available display list id`, and my screen updating with the container. If data size is very large, the update action will affect the response time of my UI. Actually I don't need immediate update, a gradually update and smooth UI is important for me.
Smile Programming
2010-10-27 06:27:07
Display lists can have up to 0xfffe vertexes, before you start experiencing problems. Try to limit the size of your lists to this number, and then see if the performances go up. This is the limit imposed by the driver
VJo
2010-10-27 07:38:04
Thanks for the information, I am now refactoring my code to `partial update`. Divide objects into `tiny fragments`... involving re-design the flow and structure... it's really painful :)
Smile Programming
2010-10-27 09:07:14