My question is simple: will there be a darwin 3.5 source package or
binary available on fink or through other sources any time soon? The
reason I ask is because the 'official' Mac 3.5 version, while decent,
doesn't offer the raw performance a straight cli app can offer, or at
least that's a theory I want to test. I think a lot of the problems
with 3.5 are due to carbon lib restrictions and the easiest way to
avoid the restrictions is to run the pure unix port.

Any info would be appreciated. Since darwin distros are unofficial, I
haven't seen any word, and so I naturally wonder about progress in this
regard.

--eli

Post a reply to this message

In article <220720021602190627%spa### [at] is-speakeasybad-net>,
Elijah Sarver <spa### [at] is-speakeasybad-net> wrote:

Oops, found my answer, august first for the basic code release. Is this
just a matter of using make?

Post a reply to this message

Elijah Sarver <spa### [at] is-speakeasybad-net> wrote:
> I think a lot of the problems
> with 3.5 are due to carbon lib restrictions and the easiest way to
> avoid the restrictions is to run the pure unix port.

  Which problems?

-- 
#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

In article <3d3dd743@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> I think a lot of the problems
>> with 3.5 are due to carbon lib restrictions and the easiest way to
>> avoid the restrictions is to run the pure unix port.
>
>   Which problems?

Supposedly that a GUI application cannot get the whole CPU for itself.  Mac
users don't like it if an application does _not_ get the whole CPU for
itself.  Don't ask me why...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Supposedly that a GUI application cannot get the whole CPU for itself.  Mac
> users don't like it if an application does _not_ get the whole CPU for
> itself.  Don't ask me why...

  So how much CPU does the GUI take? Something like 0.1%? Big deal?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d3e615c@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   So how much CPU does the GUI take? Something like 0.1%? Big deal?

No, you have to take into account that Mac OS X only has BSD as its lowest
layer.  Everything on top is basically still NextStep/OpenStep object model
side by side with a completely separate subsystem for native and emulated
Mac OS compatibility (native is Carbon, and emulated is what used to be
called BlueBox) on top of which yet another layer for the GUI.

Thanks to this cluttered design and the "Aqua" effects the average load from
the operating system (depending on what services run in the background) is
about 5%-7% on one processor on the fastest Macs available.  Moving windows
and such will consume up to 30% of all CPU resources in current versions and
about half of that in future versions of Mac OS X.

In order to let applications still appear responsive Mac OS X uses a trick:
If a GUI application (which itself is cooperatively threaded on top of the
preemptive threading of Unix threads which it is just one) "hogs" the CUP
for too long (it cannot be determined by the application what the OS defines
as too long), it gets removed from the screen update queue.  This is
possible under Mac OS X because the GUI _forces_ all windows to be double
buffered!!!  That is also why the preview window under Mac OS X causes such
a slowdown when rendering simple scenes compared to complex ones as on Macs
you get a pixel by pixel preview rather than a line by line preview.

The problem is, that it takes the OS several seconds to recognize that an
application is drawing to its windows again and to start updating the
double-buffered windows (for which one has to force redraw anyway, but the
OS my decide to ignore that as well).  The only way around this for an
application is to either get removed from screen updating and accept that,
or to return control to the OS as frequently as possible.

If you run as a Unix command-line program on the other hand, you don't have
these problems and don't get kicked out of the double buffered window
updating.  So you can hog the CPU (by changing the process priority) and the
whole system will just be less responsive.  Of course, users could also
change the process priority of the GUI application via the command-line, but
that isn't too popular...

    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

In article <3d3e5619@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Supposedly that a GUI application cannot get the whole CPU for itself.  Mac
> users don't like it if an application does _not_ get the whole CPU for
> itself.  Don't ask me why...

It's not that it should take the whole CPU, it should take all 
*available* CPU. Currently, some percentage just sits idle.

Since fixing this would require doing a lot of work on the existing GUI, 
second best solution would be to just compile the CLI version. There is 
also at least one Cocoa GUI, it isn't very complete but it would be 
better than using the command line for some.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On the other hand, command-line version of povray + emacs is the best
possible combination anyways. :)

  (Ok, ok, I like winpov, even though I miss a few emacs features.)

-- 
#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

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> It's not that it should take the whole CPU, it should take all
> *available* CPU. Currently, some percentage just sits idle.

But it cannot - as a Carbon application - without either breaking Mac OS 8/9
compatibility (switching to the Mac OS X event model) or letting Mac OS X
removed it from the update queue (and getting bug reports for not updating
windows).  Given that even Apple admits Mac OS X is only used by 10% of the
active installed base of Mac users, I have to say making any such changes
has a very low priority for the years to come.  Especially as even Apple
estimates the annual adaptation rate at 10% in the pubic...

    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

In article <3d3f0012@news.povray.org>, Warp <war### [at] tagpovrayorg> wrote:

>   On the other hand, command-line version of povray + emacs is the best
> possible combination anyways. :)
> 
>   (Ok, ok, I like winpov, even though I miss a few emacs features.)

I like winpov too. It doesn't need OS <X blessed files for it to work.
It doesn't lock up whilst saving files (happened to me yesterday, had
to force quit.. glad it wasn't important stuff) and its help file is
quite easy to navigate and is quite up to date.

There is the threading issue, which is why i want to go to the
unix-based software. I think that  that in combination with an editor
like emacs is really all one needs.

I like OSX a lot, but carbon apps just don't bridge the old and the new
very well for me. Too much abstraction can't be all good for
performance. I know what abstraction does -- i'm a performance analyst
for a software company.

Post a reply to this message