 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/3/2011 11:08, Darren New wrote:
> Actually, it seems pretty easy, relatively speaking.
http://msdn.microsoft.com/en-us/library/aa373233%28VS.85%29.aspx
Actually, it looks like XP and 2000 work the way I remember.
"""
The system initiates a sleep request by first sending a PBT_APMQUERYSUSPEND
event. Applications should not deny this request; doing so will prevent the
system from going to sleep.
"""
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3-10-2011 20:14, Darren New wrote:
> Actually, it looks like XP and 2000 work the way I remember.
I think XP did not go to sleep with a render under way. It maybe slowed
down though... I am not sure.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/09/2011 04:58, Cousin Ricky wrote:
> I start an overnight render. I wake up the next morning, expecting a beautiful,
> polished image.
>
> Instead, the damn machine has gone into sleep mode!
I've added a new 'Prevent sleep while rendering' option to avoid this
issue. It defaults to on, which is probably what most folks would want.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.01.2013 01:40, schrieb Chris Cason:
> On 28/09/2011 04:58, Cousin Ricky wrote:
>> I start an overnight render. I wake up the next morning, expecting a beautiful,
>> polished image.
>>
>> Instead, the damn machine has gone into sleep mode!
>
> I've added a new 'Prevent sleep while rendering' option to avoid this
> issue. It defaults to on, which is probably what most folks would want.
Sounds plausible indeed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 29.01.2013 01:40, schrieb Chris Cason:
> > On 28/09/2011 04:58, Cousin Ricky wrote:
> >> I start an overnight render. I wake up the next morning, expecting a beautiful,
> >> polished image.
> >>
> >> Instead, the damn machine has gone into sleep mode!
> >
> > I've added a new 'Prevent sleep while rendering' option to avoid this
> > issue. It defaults to on, which is probably what most folks would want.
>
> Sounds plausible indeed.
That is reasonable. Another thing I do immediatelly after having purchased a new
windows machine is to let it ask before downloading updates. Updates can cause a
reboot which is annoying just as well.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I've added a new 'Prevent sleep while rendering' option to avoid this
> issue. It defaults to on, which is probably what most folks would want.
Which got me thinking...
How hard would it be for winpov to detect that it was terminated while
a rendering was in progress, save that info somewhere, and then the next
time it's started for it to ask the user if they want to continue the
render?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> > I've added a new 'Prevent sleep while rendering' option to avoid this
> > issue. It defaults to on, which is probably what most folks would want.
>
> Which got me thinking...
>
> How hard would it be for winpov to detect that it was terminated while
> a rendering was in progress, save that info somewhere, and then the next
> time it's started for it to ask the user if they want to continue the
> render?
>
> --
> - Warp
I'm certainly no expert at this. But POV leaves a state file when interrupted
otherwise an image. So it should not be impossible. But with a multicore machine
the continue option works only if all threads have left no "whole" in the
picture. That means if a block is not finished but an other which is later in
the sequence the blocks are worked through from another thread is (may be the
first contains some glass the second not, so the later thread is ready before
the first) than "continue" continues behind the later thread overlooking the
"whole" from the first unfinished thread. So if you have to interrupt a
rendering since you need your machine for other purposes, you have to be lucky
to can use the +c. IMO this issue is more important then the occasional updates
or the sleeps, which can be avoided easily with the update options or the energy
options Stephen pointed out.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MichaelJF <mi-### [at] t-onlinede> wrote:
> I'm certainly no expert at this. But POV leaves a state file when interrupted
> otherwise an image. So it should not be impossible. But with a multicore machine
> the continue option works only if all threads have left no "whole" in the
> picture. That means if a block is not finished but an other which is later in
> the sequence the blocks are worked through from another thread is (may be the
> first contains some glass the second not, so the later thread is ready before
> the first) than "continue" continues behind the later thread overlooking the
> "whole" from the first unfinished thread. So if you have to interrupt a
> rendering since you need your machine for other purposes, you have to be lucky
> to can use the +c. IMO this issue is more important then the occasional updates
> or the sleeps, which can be avoided easily with the update options or the energy
> options Stephen pointed out.
Are you saying that +C doesn't currently work, or are you just guessing?
I wasn't talking about the +C option per se. I was just talking about a
possible convenience feature in winpov that would suggest the user to
continue the render if povray was closed the last time while it was
rendering.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
> > I'm certainly no expert at this. But POV leaves a state file when interrupted
> > otherwise an image. So it should not be impossible. But with a multicore machine
> > the continue option works only if all threads have left no "whole" in the
> > picture. That means if a block is not finished but an other which is later in
> > the sequence the blocks are worked through from another thread is (may be the
> > first contains some glass the second not, so the later thread is ready before
> > the first) than "continue" continues behind the later thread overlooking the
> > "whole" from the first unfinished thread. So if you have to interrupt a
> > rendering since you need your machine for other purposes, you have to be lucky
> > to can use the +c. IMO this issue is more important then the occasional updates
> > or the sleeps, which can be avoided easily with the update options or the energy
> > options Stephen pointed out.
>
> Are you saying that +C doesn't currently work, or are you just guessing?
>
> I wasn't talking about the +C option per se. I was just talking about a
> possible convenience feature in winpov that would suggest the user to
> continue the render if povray was closed the last time while it was
> rendering.
>
> --
> - Warp
No, I'm not guessing, this is an observation. We had a discussion about this
issue some months ago and Thomas de Groot observed the same. Look at
http://news.povray.org/povray.beta-test/thread/%3Cweb.5033e17517f31266b62e53d00@news.povray.org%3E/
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Seems the link vanished. Hope it can be seen now:
http://news.povray.org/povray.beta-test/thread/%3Cweb.5033e17517f31266b62e53d00@news.povray.org%3E/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
