Hi Frank,
Thanks for this very interesting clarification :-)
Le 14 mai 05, � 15:15, Frank D. Engel, Jr. a �crit :
I'd bet it's more related to the graphics architecture of the platform
than the graphics cards themselves.
Mac OS X's Aqua interface is drop-dead gorgeous, and very easy (and
fun) to work with, but that comes at a price. All of the transparency
effects, multilayer compositing, PDF-style graphics architecture (not
very well used by Rev, BTW), and so forth -- all adds up in terms of
processing cost.
OTOH, the relatively simplistic (from a processing perspective, at
least) Windows GDI architecture makes less demand on both the
processor and the graphics card, meaning faster apparent performance.
It's not that the cards on the Macs are slower, but rather that they
have more work to do to achieve similar results.
Now there is another trick involved here, which relates more to the
underlying architecture of the operating systems. Speed isn't
everything.
When early versions of Windows NT were first designed, the graphics
system was running as a user-mode "application" of sorts on top of the
Windows kernel. This helped to isolate the graphics system somewhat
from the low-level kernel code, theoretically improving system
stability and scalability. However, this kind of architecture implies
that programs need to establish interprocess communications routes
with the code implementing the graphics system. This communication
adds overhead to the system, which slows down performance.
With the release of Windows NT 4 (I think it was that version, could
be wrong), the graphics system was moved into the kernel (M$ may argue
that it was moved into the "executive" and that the kernel is
something different, perhaps on a block diagram that may be true, but
from the computer's perspective they are two parts of the same thing).
This has the effect of substantially reduce the overhead involved in
accessing the graphics system by allowing calls to the graphics system
to pass through from the app to the graphics system without the extra
manipulations required to get that data to another app. This helps to
make the Windows graphics architecture one of the *fastest* ones
around - -- but this also comes at a cost.
Placing the graphics code in the kernel adds complexity to one of the
most important parts of the operating system. This added complexity
makes maintenance more difficult, promotes decreased stability, and
makes it harder to recover when something goes wrong. It also has a
nasty effect on security:
Kernel-level code can access any part of the computer system. An
exploitable bug in that code could give someone complete access to the
entire computer system. With so much code in the kernel layer,
Windows is a security risk no longer waiting to happen (just look at
all of the viruses and so forth which have hit the news for Windows --
and that's just for starters). The less code in the kernel, the
easier it is to verify absence of such security holes, and the easier
it is to enforce security on the system (note that this assumes all
else being equal -- an incredibly good kernel running underneath
horribly pathetic software will not make that software secure by any
means).
Microsoft has this nasty habit of increasing performance by moving
lots and lots of code into the kernel. This increases speed, and yes,
Windows is very, very fast (it has to be to get away with running on
relatively poor hardware). But that speed is at the expense of
stability and security.
Mac OS X, on the other hand, has an extremely small kernel, much
smaller than most. The graphics system and so forth are running as
userland processes, much as the graphics system was originally
designed to under Windows NT. This means lower performance, but it
helps to improve stability and security on the system.
So in other words, OS X gives up some of the cheap-thrill speed of the
Windows architecture in order to help protect its users from the
security and stability issues which are so rampant on the Windows
platform.
It's a design choice.
On May 14, 2005, at 5:43 AM, Eric Chatonet wrote:
Hi Richard,
Working with both Macs and PCs, I am always surprised by the BIG
difference between graphic cards speeds.
I have to say that graphic cards on Macs are very slow compared to
even cheap PC cards...
For instance, you use a dissolve effect FAST on a Mac since it
appears too slow without adding fast.
Then you put the stack on a PC and you don't see nothing: It's
already too fast :-)
All visual features where a delay can't be set (as for the move
command) have to be changed according to the platform.
Some of them can't be used on Macs: everybody does not own a G5 2*2.7
GHz :-(
BTW Chipp's stack works great on any PC...
Best regards from Paris,
Le 14 mai 05, � 08:12, Richard Gaskin a �crit :
Chipp Walters wrote:
try in the message box:
go URL "http://www.gadgetplugins.com/chippstuff/KBmain.rev";
I apppreciate your putting that together, but alas on my 1GHz Mac
it's fairly choppy. :(
Does it look smooth on your machine?
Amicalement,
Eric Chatonet.
----------------------------------------------------------------
So Smart Software
For institutions, companies and associations
Built-to-order applications: management, multimedia, internet, etc.
Windows, Mac OS and Linux... With the French touch
----------------------------------------------------------------
Web site http://www.sosmartsoftware.com/
Email [EMAIL PROTECTED]/
Phone 33 (0)1 43 31 77 62
Mobile 33 (0)6 20 74 50 86
----------------------------------------------------------------
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
