POV-Ray : Newsgroups : povray.bugreports : Bug report/feature request? Server Time
22 Nov 2024 19:24:39 EST (-0500)
  Bug report/feature request? (Message 1 to 7 of 7)  
From: Duane Tackett
Subject: Bug report/feature request?
Date: 12 Oct 1998 05:56:28
Message: <3621c43c.0@news.povray.org>
Guys,

    I was using my computer at work to render something and I needed my
machine for a few seconds, so I paused the render.  To my surprise the clock
kept ticking!  Wouldn't it make sense to pause the clock so you can get an
accurate representation of how long it took a render to complete?  So tell
me, is this a bug or a feature request?  Thanks in advance for a great job
with the new version...I LOVE it!

--
Duane

Check out my web page.  I just started, so don't laugh too hard.
http://www.geocities.com/siliconvalley/lab/8407
e-mail me: ddt### [at] junocom


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Bug report/feature request?
Date: 12 Oct 1998 13:26:47
Message: <36222dc7.0@news.povray.org>
"Duane Tackett" <ddt### [at] junocom> wrote:
>
>    I was using my computer at work to render something and I needed my
>machine for a few seconds, so I paused the render.  To my surprise the clock
>kept ticking!  Wouldn't it make sense to pause the clock so you can get an
>accurate representation of how long it took a render to complete?  So tell
>me, is this a bug or a feature request?  Thanks in advance for a great job
>with the new version...I LOVE it!

Its a feature request: You will never get an accurate timing on any multi-tasking
system. Pausing a render simply makes the problem more obvious.


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany


Post a reply to this message

From: Lapo Luchini
Subject: Re: Bug report/feature request?
Date: 12 Oct 1998 18:20:56
Message: <362272A9.3D47DD7C@usa.net>
Thorsten Froehlich wrote:

> Its a feature request: You will never get an accurate timing on any multi-tasking
system. Pausing a render simply makes the problem more obvious.

I think you could obtain easily the seconds of CPU occupation (task manager and wintop
do it someway).. and I think that's the best counter of time
used.. it pauses when the CPU is not used, even if taken by other programs and not by
a pause of the user..

Or it isn't that simple?

Bye!

--

Lapo 'Dr.Brain' Luchini
mailto:lap### [at] usanet (PGP Key on keyservers)
http://lapo.home.ml.org (ICQ UIN: 529796)


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Bug report/feature request?
Date: 12 Oct 1998 19:54:18
Message: <3622889a.0@news.povray.org>
Lapo Luchini <lap### [at] usanet>  wrote:
>I think you could obtain easily the seconds of CPU occupation (task manager and
wintop do it someway).. and I think that's the best counter of time
>used.. it pauses when the CPU is not used, even if taken by other programs and not by
a pause of the user..
>
>Or it isn't that simple?

Yes and no: Yes, it could be possible to get the time the process was active, but no,
it is not possible to get an accurate time because you still have the process mamager
overhead (switching, getting the time etc.) and so the longer the rendering the larger
the overhead. I would guess it is a few seconds per hour and you would not have them
with a single task system like DOS (ok, its interrupts will add a few microseconds as
well...).

However, you are right that using the CPU usage would be much more accurate than the
current implementation, but image all the programming overhead - there are simply more
important things to do than to implement a better working render time calculator...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany


Post a reply to this message

From: Dan Connelly
Subject: Re: Bug report/feature request?
Date: 12 Oct 1998 20:30:56
Message: <36229116.20CA86BF@flash.net>
Thorsten Froehlich wrote:
> 
> Its a feature request: You will never get an accurate timing on any multi-tasking
system. Pausing a render simply makes the problem more obvious.

So would multiplying it by a random number from 0.5 to 2 :).

The point is to get the best estimate available.  When I do long images, I pause them
when
I want to do other business on my W95 machine, which handles multitasking quite poorly
relative to a UNIX system.  Thus the CPU available to POV, when it is rendering, is
relatively constant. 

I think shutting the clock off during pause is a fine idea.

Dan

-- 
http://www.flash.net/~djconnel/


Post a reply to this message

From: Lapo Luchini
Subject: Re: Bug report/feature request?
Date: 14 Oct 1998 03:10:56
Message: <3624406C.D683068C@usa.net>
Thorsten Froehlich wrote:

> However, you are right that using the CPU usage would be much more accurate than the
current implementation, but image all the programming overhead - there are simply more
important things to do than to implement a better working render time calculator...

Yeah, for sure... and anyway who wants to know THAT time can actually use TaskManager
(NT) or WinTOP (95)... he will get at most an extra second for the time spent in the
menu to select image etc..

Bye

--

Lapo 'Dr.Brain' Luchini
mailto:lap### [at] usanet (PGP Key on keyservers)
http://lapo.home.ml.org (ICQ UIN: 529796)


Post a reply to this message

From: Duane Tackett
Subject: Re: Bug report/feature request?
Date: 19 Oct 1998 12:31:16
Message: <362b5b44.0@news.povray.org>
Dan Connelly wrote in message
>I think shutting the clock off during pause is a fine idea.
>
>Dan
>
>--
>http://www.flash.net/~djconnel/

Which a) given  the fact that "If Pause=1 then don't increment time" type of
scenario looks fairly simple and B) it was just a minor annoyance should
combine to make a request falling somewhere between "If we feel like it" and
"the apocalypse".  Let me just state it again, POV 3.1 is awesome!

I actually do have one more dumb question:  why is the executable named
povwin3 and not povwin31???  Just curious...


Duane

Check out my web page.  I just started, so don't laugh too hard.
http://www.geocities.com/siliconvalley/lab/8407
e-mail me: ddt### [at] junocom


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.