1)

In the middle of RTRT::internalRenderLoop(),

channel->display->displayImage(myContext, image);

draws the ray traced image via glDrawPixels(), provided myContext.proc == 0.

Could it be possible that any non-primary thread (proc!=0) that has reached rendering calculation code:

currentImageTraverser->renderImage(myContext, image);

would contaminate the ray traced image buffer prior to glDrawPixels() finish? I don’t know if I have missed seeing Barrier objects or other synchronization safe guards between those these blocks.

2)

I am creating a new management thread (a different Runnable class than Worker) that listens to system level events. And it is in this thread the ray traced buffer should be blit to screen via channel->display->displayImage(myContext, image), which calls glDrawPixels().

Simultaneously, all other threads would be in RTRT::internalRenderLoop() focusing exclusively on the rendering of the tiles as assigned by LoadBalancer.

While this tentatively works, related to 1), I don’t see a clear mechanism that lets the management thread finish glDrawPixels(), while blocking the other rendering only threads from contaminating the image. (Indeed, I am seeing tiles from the current and next frames simultaneously on screen if the scene is in motion).

3)

I see a lot of if( proc == 0), or if( firstFrame ) special cases. I wish to eventually refactor them into my management thread. Would this be disadvantageous (along with the management thread idea), as the current architecture has all threads running the same internalRenderLoop() function, perhaps so they can easily be managed by Barrier objects?

Thanks

Bo Huang