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

> It doesn't lock up whilst saving files (happened to me yesterday, had
> to force quit.. glad it wasn't important stuff)

Don't expect anything you find to be fixed if you don't report it. So far
nobody has reported one when saving files throught the whole alpha, beta or
final version releases. Or do you really think I would leave a crashing bug
in the program just to annoy users?

> and its help file is
> quite easy to navigate and is quite up to date.

??? You do realize that the help files are identical (except for the
platform specific section 1) in all distributions of POV-Ray 3.5 ???

Are you sure you are using POV-Ray 3.5 from www.povray.org or
mac.povray.org?

    Thorsten

Post a reply to this message

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

> > It doesn't lock up whilst saving files (happened to me yesterday, had
> > to force quit.. glad it wasn't important stuff)
> 
> Don't expect anything you find to be fixed if you don't report it. So far
> nobody has reported one when saving files throught the whole alpha, beta or
> final version releases. Or do you really think I would leave a crashing bug
> in the program just to annoy users?

> ??? You do realize that the help files are identical (except for the
> platform specific section 1) in all distributions of POV-Ray 3.5 ???
> 
> Are you sure you are using POV-Ray 3.5 from www.povray.org or
> mac.povray.org?

In order to report a bug, I would have to be able to reproduce it. I
believe I can, but I'll need to find the code I pasted last time which
locked up the application during a save.

The file named "POV-Ray Documentation in HTML.html" tries to load
classic Netscape.

The copy in POV-Ray help is indeed the same version as the Windows
version. If there is a problem with the documentation on the Mac then
it must be with the documentation in general, and I'll check it against
my windows copy. I will pass problems on to documentation.

Post a reply to this message

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

> The file named "POV-Ray Documentation in HTML.html" tries to load
> classic Netscape.

Well, that is a problem with your file-mapping asking all HTML files to be
opened by Netscape.  It is a plain and simple HTML text file and thus will
open in any browser (drag it on a browser window is anything else fails),
but POV-Ray cannot fix configuration problems for you especially if they
involve something like the default browser being used...

    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

> Well, that is a problem with your file-mapping asking all HTML files to be
> opened by Netscape.  It is a plain and simple HTML text file [...]

Actually, it's a plain and simple HTML text file with a creator code of
"MOSS" (Netscape). Of course it can be dragged to a different browser, and
MacOS X allows to remap all Netscape TEXT documents to a different
Application, but I wouldn't call it a "Configuration Problem" when the file
mapping is set to open Netscape files with Netscape. Don't blame everything
on the end user.
What does the OS 9 Finder do for .html files with extension, file type TEXT
but blank creator code? Does it do the "Right Thing"? (that's the best
option for MacOS X). If that works, I'd strongly suggest that for the next
release (if not, nothing can be done anyway).

Cheers,
Wolfgang

Post a reply to this message

In article <3d45cdb4@news.povray.org> , "Wolfgang Thaller" 
<wol### [at] gmxnet> wrote:

> What does the OS 9 Finder do for .html files with extension, file type TEXT
> but blank creator code?

Open in a text editor as expected.  Also if one removed type and creator
code completely it may work depending on the file exchange settings.
However, it renders the file unusable if file exchange is not enabled.

So in short, unless I provide such files for every browser available, it
won't be possible to change it.  Of course, one can always simply use the
help center version of the docs (which is where that page links to).


    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