POV-Ray : Newsgroups : povray.unix : Darwin 3.5? : Re: Darwin 3.5? Server Time
28 Jul 2024 10:28:47 EDT (-0400)
  Re: Darwin 3.5?  
From: Thorsten Froehlich
Date: 24 Jul 2002 04:32:45
Message: <3d3e662d@news.povray.org>
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

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