 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Whoops, that patch shouldn't have been wrapped...
% 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)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Mar 2003 12:36:28 -0700, Charles Albrecht
<cha### [at] po-remove-box com> wrote:
> Using the official 3.5, build 0173 for Macintosh...
Have you verified this behaviour with latest release POV-Ray 3.5.1 Public
Release Candidate 1 (expires March 25th) from
<http://mac.povray.org/download/macosx102.html> ?
> The cause itself is in the core and not in the macintosh-specific
> portions of the codebase.
Don't you think that community more benefit with such report in case it is
posted in not platform specific group ? :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <fvqp6vkjp88qred96k5amosmp05rnumvh8@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
>
> Have you verified this behaviour with latest release POV-Ray 3.5.1 Public
> Release Candidate 1 (expires March 25th) from
> <http://mac.povray.org/download/macosx102.html> ?
On my G3, I cannot verify against the latest release candidate because
the engine for the latest release candidate does not run on anything
other than a G4.
> Don't you think that community more benefit with such report in case it is
> posted in not platform specific group ? :-)
I tried crossposting to povray.bugreports, but when crossposting, the
message never showed up.
-C
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: "Overall total time" counts "Parse time" twice? (3.5 0173)
Date: 10 Mar 2003 18:42:05
Message: <3e6d22cd@news.povray.org>
|
|
|
| |
| |
|
|
Thanks, but this has been fixed a long time ago.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Ian J Burgmyer
Subject: Re: "Overall total time" counts "Parse time" twice? (3.5 0173)
Date: 10 Mar 2003 21:34:43
Message: <3e6d4b43$1@news.povray.org>
|
|
|
| |
| |
|
|
Charles Albrecht's furious key-hammering produced this:
>> Don't you think that community more benefit with such report in case it is
>> posted in not platform specific group ? :-)
>
> I tried crossposting to povray.bugreports, but when crossposting, the
> message never showed up.
I think povray.bugreports is moderated, so posts wouldn't show up immediately.
--
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6d22cd@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Thanks, but this has been fixed a long time ago.
>
> Thorsten
When I saw how old the released source was, I thought that might be the
case.
-C
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
