Hello All,

I am using OpenGL to facilitate cross platform video playback (Mac / Windows) - a pipeline performs the rendering of video frames and then at the end of the pipeline there exists a drawing phase with at least two threads that make use of OpenGL to render the video frames onscreen in different locations; for the purpose of this description assume one OpenGL context is rendering to a view inside of the screen area of the App and a second OpenGL context is rendering to another view that is fullscreen representation of the video on a secondary monitor. There is a master thread that receives the video frame to be visualized, which takes this frame and passes it along to the visualization threads, the master thread keeping everything in sync so that both visualization threads are visualizing the same frame at the same time. Knowing that OpenGL contexts purportedly behave best by living by themselves on separate threads, the contexts being used to perform this multithreaded drawing are created and destroyed on these separate visualization threads. Additionally, when each thread is drawing it ensures that its own context is current. The issue that I am running into indicates to me that the most likely cause for the issue is some type of cross talk in either the setting up of the GL Viewport or in the setting of the GL Matrices.

The symptoms are as follows:
The App is set up to perform visualization of the video in a pillar-box or letter-box format (that being to scale the video frames to fit just inside the viewport, filling either the top and bottom OR left and right of the viewport with black as necessary to fill up unused area in the event the video frame and the viewport are not of the same aspect ratio). To do this, the App clears the OpenGL context to black, creates a poly to fit just inside the viewport and at the aspect ratio of the video frame, then loads the video frame into texture memory and skins the poly with the texture. However, when there exists two visualization threads/contexts it appears as if the sizing of this poly gets wonky by way of sharing viewport information (or perhaps projection/modelview matrix info) between the two rendering contexts - or at least this is the best I can figure out. What happens is that either both visualizations get imaged to the full size of the viewports or both visualizations get letter/pillar boxed the exact same way, even when the aspect ratios of the two viewports are different and so the two visualizations should be letter/pillar boxed differently. When I step through the code, each visualization is computing the size and placement of the poly vertices properly and so each visualization should be performed correctly, which leads me to thing something pertaining to the the projection matrix or the viewport is getting shared between the threads (though I am stepping through and so am isolating one thread). When the code is run at full speed the visualizations twitch in aspect ratio as on any given frame either both visualizations seem to be pulling viewport or matrix information from one or the other contexts.

Incidentally, this only occurs when both contexts have the same properties for the pixel format. When the contexts have different properties for the pixel format all drawing behaves as expected. I have read in other posts to this forum that multiple windows having the same pixel format need only one context - so there seems to be something special, context-wise, with regard to the pixel format - perhaps that contexts really care primarily about pixel formats (which makes sense). Is it possible that there is an internal optimization going on when the pixel formats of my two contexts are the same that is squashing the attempt at drawing to these separate contexts concurrently? If so, is there anyway to disable such optimization? Additionally, all of the above described information is the same when the App is run on either a Windows machine using an NVIDIA GPU or a Mac laptop using and AMD/ATI GPU and so I am certain that the problem is something in my code somewhere.

From what I described above, does anyone have any insight? I would be happy to supply more info if necessary.

Thanks in advance,
Josh Bodinet