On 24/10/2014 at 01:03, xxxxxxxx wrote:
Hi Joey/Mohamed,
Mohamed:
when I render to picture viewer using the same software renderer (and started through the render to picture viewer command), it appears to render quicker than what it does via my custom thread using the same settings. Don't know if that means anything or not.
Joey:
the RENDERFLAGS_SHOWERRORS doesn't seem to report anything that I can see. Are the errors meant to pop up in a MessageDialog or something similar? Or is this what triggers the different RENDERRESULT flags?
Just to address some of the points you've listed:
1: The only gui related code in the thread is a call back to the dialog to redraw the user area (redraw is done via UA->Redraw(TRUE)). This call is only made once during the thread cycle.
2: No input states in code, none necessary to have.
3: Now, what I'm doing is passing a dialog class level MultipassBitmap array reference for the thread to draw too. Does this fit under the "global structure" you mention?
4: Regarding code safety, I have some if() statements in the thread's Main() that are checked before doing any rendering, so that the thread can be stopped if references are null, invalid, don't need drawing etc. All container/object references are built before the dialog is opened, and the thread is only run from the dialog. The dialog is opened via the object plugin. Do any of these containers fall under the point 3 rule too?
5: can't think of any deadlock possibilities, as mentioned, any containers related to the dialog and thread are made before the dialog is opened, and nothing that I can think of needs to wait on the thread to do anything.
Here's the two thread functions that relate to the render process, first one's setting the render settings container which looks like this:
void MY_THREAD::SetRenderSettings(void)
{
// RenderSettings & SceneDocument are a thread-class level BaseDocument and BaseContainer
// Time is a thread-class level object
// Resolution_X & Resolution_Y are also thread-class level, and are set prior to the Thread.Start() call
RenderSettings = SceneDocument->GetActiveRenderData()->GetData();
RenderSettings.SetLong(RDATA_RENDERENGINE,RDATA_RENDERENGINE_PREVIEWSOFTWARE);
RenderSettings.SetBool(RDATA_SAVEIMAGE,FALSE);
RenderSettings.SetReal(RDATA_XRES,Resolution_X);
RenderSettings.SetReal(RDATA_YRES,Resolution_Y);
RenderSettings.SetBool(RDATA_ALPHACHANNEL,TRUE);
RenderSettings.SetBool(RDATA_STRAIGHTALPHA,TRUE);
RenderSettings.SetLong(RDATA_FRAMESEQUENCE,RDATA_FRAMESEQUENCE_MANUAL);
Time.SetDenominator(Frame_Rate);
Time.SetNumerator(1);
RenderSettings.SetTime(RDATA_FRAMEFROM,Time);
RenderSettings.SetTime(RDATA_FRAMETO,Time);
}
And here's the thread's Main() function:
void MY_THREAD::Main(void)
{
// SceneDocument is a thread-class level variable
SceneDocument = GetActiveDocument();
if(SceneDocument == NULL)
{
GePrint("SceneDocument is NULL, returning");
return;
}
Initial_Go_Frame = Start_Frame;
RENDERRESULT Result = RenderDocument(SceneDocument,RenderSettings,NULL,NULL,Frame_Container->operator[](Initial_Go_Frame)->GetLayerNum(1),RENDERFLAGS_EXTERNAL|RENDERFLAGS_SHOWERRORS,this->Get()); // RENDERFLAGS_NODOCUMENTCLONE|
if(Result == RENDERRESULT_OK) // RENDERFLAGS_NODOCUMENTCLONE|RENDERFLAGS_NODOCUMENTCLONE
{
GePrint("Frame " + LongToString(1) + " complete..");
}
else
{
if(Result == RENDERRESULT_USERBREAK)
{
GePrint("Rendering:User stopped");
return;
}
if(Result == RENDERRESULT_OUTOFMEMORY){GePrint("Rendering:Out of memory");}
else if(Result == RENDERRESULT_ASSETMISSING){GePrint("Rendering:Asset(s) missing");}
else if(Result == RENDERRESULT_SAVINGFAILED){GePrint("Rendering:Failed to save");}
else if(Result == RENDERRESULT_GICACHEMISSING){GePrint("Rendering:Missing GI cache");}
}
GePrint("Thread drawing finished..");
}
There are some omissions from the above code block, but they are only flag checks and testing for the ok to go ahead and render. One line also missing is the user area redraw as mentioned, but other than that there's nothing else there. I think that's pretty much it regarding the thread. Let me know if you need more to go on.
WP.