First, the proposed patch, generated based on the following revision:

/*
* $File: //depot/povray/3.5/source/povmsend.cpp $
* $Revision: #25 $
* $Change: 1896 $
* $DateTime: 2002/08/19 04:15:16 $
* $Author: thorsten $
* $Log$
*/

Extracted from 
  http://www.povray.org/ftp/pub/povray/Official/Macintosh/povmac_s.sit
for the 3.5 release. I notice that the unix sources from
  ftp://ftp.povray.org/pub/povray/Official/Unix/povuni_s.tgz
have an older version of povmsend.cpp.


% diff -c povmsend.cpp povmsend.cpp_patch
*** povmsend.cpp        Mon Mar 10 11:48:24 2003
--- povmsend.cpp_patch  Mon Mar 10 11:48:00 2003
***************
*** 911,919 ****
        if(err == kNoErr)
           BuildRTime(&msg, kPOVAttrib_FrameTime, tp, th, tr, tp + th + 
tr);
        if((opts.FrameSeq.FrameType == FT_MULTIPLE_FRAME) && (err == 
kNoErr))
           err = BuildRTime(&msg, kPOVAttrib_AnimationTime,
!                           tparse_total + tp, tphoton_total + th, 
trender_total + tr,
!                           tparse_total + tphoton_total + trender_total 
+ tp + th + tr);
        if(err == kNoErr)
           err = POVMSMsg_SetupMessage(&msg, kPOVMsgClass_RenderOutput, 
kPOVMsgIdent_RenderTime);
        if(err == kNoErr)
--- 911,920 ----
        if(err == kNoErr)
           BuildRTime(&msg, kPOVAttrib_FrameTime, tp, th, tr, tp + th + 
tr);
        if((opts.FrameSeq.FrameType == FT_MULTIPLE_FRAME) && (err == 
kNoErr))
+          /* tparse_total and tphoton_total already include the frame 
contribution */
           err = BuildRTime(&msg, kPOVAttrib_AnimationTime,
!                           tparse_total, tphoton_total, trender_total + 
tr,
!                           tparse_total + tphoton_total + trender_total 
+ tr);
        if(err == kNoErr)
           err = POVMSMsg_SetupMessage(&msg, kPOVMsgClass_RenderOutput, 
kPOVMsgIdent_RenderTime);
        if(err == kNoErr)



Using the official 3.5, build 0173 for Macintosh...

I have noticed that during the rendering portion of multiframe 
renderings 
- FT_MULTIPLE_FRAME - the frame parse time, tparse_frame, appears to be 
counted twice when calculating the overall time for display in the 
rendering window. At the end of the render phase, the total drops back 
down to the correct value as it begins parsing again.

The observed behavior is detailed at the end..

At worst, this is merely a cosmetic issue.

The cause itself is in the core and not in the macintosh-specific 
portions of the codebase.

In povray.cpp, FrameRender() includes this section at the beginning of 
rendering.

   // Get total parsing time.
   tparse_total += tparse;
   tparse_frame = tparse;
   tparse = 0;

Later, within FrameLoop(), each call to:  
    Send_RenderTime(0, 0, 0);

Sends the animation time messsage using:

if((opts.FrameSeq.FrameType == FT_MULTIPLE_FRAME) && (err == kNoErr))
   err = BuildRTime(&msg, kPOVAttrib_AnimationTime,
       tparse_total + tp, tphoton_total + th, trender_total + tr,
       tparse_total + tphoton_total + trender_total + tp + th + tr);

(here, tp == tparse_frame)

However, tparse_total already includes the contribution from 
tparse_frame. 
In fact, tparse_frame is zero up until the point at which it is 
assigned - right after its contribution is added to tparse_total. The 
same is true of tphoton_frame, so the patch takes that into account as 
well. I don't have a CodeWarrior install (for macintosh compile), so 
I haven't performed a test build, but the patch should address the 
cosmetic display problem of rendering information during 



The observed behavior is this - with a model that parses in 30 seconds 
and renders in 60 seconds. 

During Parsing:

Parse Time: 0:00
Render Time: 0:00
Total Time: 0:00
Overall Total Time: 0:00

1 second into Rendering:

Parse Time: 0:30
Render Time: 0:01
Total Time: 0:31
Overall Total Time: 1:01

Just before rendering ends

Parse Time: 0:30
Render Time: 0:60
Total Time: 1:30
Overall Total Time: 2:00

Start of new parsing phase

Parse Time: 0:00
Render Time: 0:00
Total Time: 0:00
Overall Total Time: 1:30

I'll issue a formal bug report using the mac.povray.org website.

-Charles

Post a reply to this message