Hello All,
I have some questions pertaining to the management of multiple OpenGL contexts in a multithreaded environment (and pertaining to deterministically drawing into these contexts). I have created a crossplatform video playback library (Mac/Win) that makes use of OpenGL for the purpose of visualizing in one or more windows realtime video as it exists on a Non-Linear Editor timeline (NLE). Currently it is straightforward for discrete OpenGL contexts to exist for each of possibly multiple windows being used to visualize the frames of the video as the performance of drawing to each window in synchronous fashion has always been acceptable. Thus, my presentation thread synchronously goes through each window, setting the OpenGL context for that window to be the active context, draws the video to a poly, and then continues on to the next window performing essentially the same action, etc. Easy stuff.
I am now facing the prospect of creating a control that visualizes this NLE timeline and that allows a user to intuitively edit a movie in a fashion akin to Adobe Premiere Pro or Apple’s Final Cut Pro, all of which will feed this crossplatform video playback library. As such, it would also be ideal for this control to be crossplatform as well - and so my ideal choice would be to also implement the visualization/editing control for the timeline using OpenGL. It is important to note that the NLE timeline visualization will be constantly updating while the video is being played back to as to show the position of the playhead, etc. From my current level of understanding of the behavior of OpenGL in a multithreaded environment, all of this leads to some concerns.
From my understanding, even in a multithreaded environment, only one OpenGL context can be active at a single point in time - essentially only one OpenGL context active at a time per process; this is correct, no? If so, then within a multi-context environment to guarantee drawing is occurring in an expected context, some type of global sync object (such as a lock) must be used. This lock would ensure that ‘Thread-B’ does not switch the OpenGL context while ‘Thread-A’ is (expecting to be) performing drawing operations into the context made active by ‘Thread-A’ immediately prior to commencing with its drawing routines. In such a scenario, each thread would lock access to OpenGL, switch to the desired context, perform drawing, then release access to OpenGL. Overall, is this understanding valid?
If my understanding is valid, an important question I have is the following: As the visualization of the video frames is more important to be in realtime than the visualization of the NLE timeline, is it possible break up drawing to / flushing of the NLE context over many sessions of that context being active? As I don’t want to ever interrupt the thread visualizing the actual video frames, can I perform the following?:
- Set the NLE context and perform a portion of the necessary drawing explicitly w/o flushing this context
- Switch over to the video frame presentation context and draw the video frame to a poly and then flush this context
- Switch back to the NLE context and continue drawing from where I left off in 1) and then flush to get the scene drawn in 1) and 3)
Or do I have to perform all drawing in a single context session once I set the context as being active. As OpenGL is a state machine, I would expect that I could perform the above 1) - 3) procedure, but I don’t want to bank on that fact w/o doing a little snooping. Additionally, I am assuming there are some out there that have successfully used multiple contexts to essentially create different concurrent realtime visualizations of the selfsame data set? If so, any pointers or admonitions pertaining to the task would be very much appreciated.
Thanks in advance,
Josh