Mac and PCs graphic speeds (was: Ken Burns Effect in Rev?)

[Eric Chatonet]

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		eric.chatonet at sosmartsoftware.com/
Phone		33 (0)1 43 31 77 62
Mobile		33 (0)6 20 74 50 86
----------------------------------------------------------------