 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ryan Mooney" <rdm### [at] earthlink net> wrote in message
news:3C6A01B9.AC12F62A@earthlink.net...
> Abyss.pov FREEZE
>
> Abyss.pov is STILL freezing my mac... =[
> Problem from beta 9... ???
Not happening here in WinPOV beta 11 icl on a WinXP system.
At what point does it freeze? During parse, bounding slabs, vista buffer,
light buffer, or render?
bob h
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Abyss.pov FREEZE
>
> Abyss.pov is STILL freezing my mac... =[
> Problem from beta 9... ???
Works fine with me.
WINPOV Beta 11, WIN 98SE, P3 600, 128 MB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Render...
In the first pixel of the first line... ??
After Parse... ??
bob h wrote:
> "Ryan Mooney" <rdm### [at] earthlinknet> wrote in message
> news:3C6A01B9.AC12F62A@earthlink.net...
> > Abyss.pov FREEZE
> >
> > Abyss.pov is STILL freezing my mac... =[
> > Problem from beta 9... ???
>
> Not happening here in WinPOV beta 11 icl on a WinXP system.
>
> At what point does it freeze? During parse, bounding slabs, vista buffer,
> light buffer, or render?
>
> bob h
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ya i am using a Macintosh iBook OS 9.2...
Ill keep on about it... =]
Felix Wiemann wrote:
> > Abyss.pov FREEZE
> >
> > Abyss.pov is STILL freezing my mac... =[
> > Problem from beta 9... ???
>
> Works fine with me.
> WINPOV Beta 11, WIN 98SE, P3 600, 128 MB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ryan Mooney <rdm### [at] earthlinknet> wrote:
: In the first pixel of the first line... ??
Perhaps it's just slow?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Its a power book it can not be that slow, or someone changed the laws of
physics... just joking... everything is froze the mouse pointer, the program,
it will not even "Force Quit"
Completely frozen... Why... ??
Warp wrote:
> Ryan Mooney <rdm### [at] earthlinknet> wrote:
> : In the first pixel of the first line... ??
>
> Perhaps it's just slow?
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ryan Mooney <rdm### [at] earthlinknet> wrote:
> Its a power book it can not be that slow, or someone changed the laws of
> physics... just joking... everything is froze the mouse pointer, the program,
> it will not even "Force Quit"
> Completely frozen... Why... ??
Confirmed. Beta 11, Powerbook G3 266MHz, 192MB RAM, MacOS 9.2.2 US;
rendering 320*120, all other settings default.
Closer analysis reveals it's a memory issue:
With the default allocation of 14919K it freezes right at the beginning of
parsing.
25000K - freeze somewhere in the middle of parsing.
45000K - quit with error 1 at "Creating bounding slabs".
48000K - "
49000K - freeze in the middle of rendering line 10.
50000K - renders fine.
Ryan, if you have time, could you have a look at my "Mac GUI partial image
oddities" (http://news.povray.org/povray.beta-test/21765/)?
Thorsten says he is unable to reproduce it, while I am unable not to
reproduce it.
-Christian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <B896A062.2CCD%cwa### [at] gmxch> , Christian Walther
<cwa### [at] gmxch> wrote:
> Closer analysis reveals it's a memory issue:
> With the default allocation of 14919K it freezes right at the beginning of
> parsing.
> 25000K - freeze somewhere in the middle of parsing.
> 45000K - quit with error 1 at "Creating bounding slabs".
> 48000K - "
> 49000K - freeze in the middle of rendering line 10.
> 50000K - renders fine.
Ah, thanks! I could now reproduce it and it will be fixed in the next beta.
Of course, 50 MB will still be required to render abyss.pov!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c70efb5@news.povray.org...
<snip>
Just out of curiousity, and for us non-mac-aware-bods, what sort of bug is this
and how is it resolved?
How is the default allocation set - by the prog., the system or the user? Can it
change dynamically (i.e. as the prog. is running and requires it)?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c70f302$1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:
> Just out of curiousity, and for us non-mac-aware-bods, what sort of bug is
> this and how is it resolved?
Well, like with all out of memory bugs, one has to make sure really everything
checks if malloc didn't return NULL. Overlooking one in a thousand different
calls to malloc is enough to cause such a problem, given there isn't enough
memory at the right time.
> How is the default allocation set - by the prog., the system or the user? Can
> it change dynamically (i.e. as the prog. is running and requires it)?
Oh, on Macs one can set a upper and lower limit. Programs are allowed to
request additional memory in the background when they detect they ran out of
memory*, but in general this is not recommended as usually the user has set
the limit for a reason. POV-Ray for Mac OS is (supposed to come) configured
such that one can render all demo scenes with the default limits, but the
limits I am using are still based on what used to be "big" demo scenes that
came with 3.1g. Obviously, certain scenes in the advanced folder of 3.5
require much more memory...
Unfortunately Mac OS X no longer has such a flexible allocation scheme
accessible for users unless they want to play with the plain Unix shell :-(
Thorsten
* The recommended rule for a programmer is that one should use this additional
memory only for a short time. For example compilers do it when compiling
larger applications - the syntax trees and such can take much more memory than
needed for normal operation, but only for a short time, of course.
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
