[cgrscott]

Yes, you are right about the USB boot-ability on Intel Macs. That is encouraging and many of the newer camcorders connect to iMovie by USB, instead of FireWire. One could complain about not being able to connect their older Mini-DV camcorder to the new Macbook but you can get a new Mini-DV or flash-memory camcorder for under $200, with USB connectivity to iMovie. So the Macbook's limited I/O is calculated and on purpose, pointing to the future of hardware and not the past.
I will probably go with the Macbook Pro for a little better graphics performance, the larger screen for Adobe Creative Sweat, and to satisfy my need for legacy compatibility with FireWire.
The new Aluminum Macbooks and Macbook Pros are very sexy.
Rob

[sujovian]

IEBA1 said:

sujovian, let me give you an example from my direct experience which proves how FCP relies heavily on the GPU:

New Mac Pro, 8 cores, 10 GB RAM, Full 1920x1080i footage in Apple ProRes422.
Internal RAID capable of nearly 300 MBps.

In FCP-6, Take the video clip and create five 50% opaque layers.
Set the RT manager to Unlimited RT, Dynamic frame rate, Dynamic quality.
Launch Activity Monitor, and have it show the activity meter for all the CPUs.
Put your cursor at the head of the timeline and click play.
The processors do almost nothing while the video plays and all the layers are displayed.
Stop playback.

Anthony, You're misunderstanding how RT Extreme works, which is particularly accentuated when you use Dynamic Framerate and Dynamic Quality settings. It operates by discarding frames and resolution in the RAM preview to play through these clips in realtime at reduced quality. This is why you'll still always render the timeline out before laying off to tape. Reduced quality = reduced CPU load. Try doing the test again at full frame rate and high quality, and you'll likely see some increase in CPU load.

An 8-core mac pro is actually a bad machine to do this test, because under most activities FCP is only working off two of the 8 cores, so even if you were pegging those two cores, your activity meter will only hit about 12.5%. Try doing this same test on an iMac or even a Macbook (GMA950), where each processor gets it's own bar. Offset your clips so that you're adding an extra layer every few seconds. You'll see the CPU workload increase over time as you add streams, even with just DV25 content. You'll also see that having a low powered GPU vs a high powered GPU makes little to no difference on how hard the CPU gets hit during this operation.

Quote

Then,
Click Option-R for a forced render of all non Safe-RT effects.
NOW all the processors kick into high gear, rendering the footage in non-real-time.
The Activity Monitor meters will jump like crazy.

When you actually do a full forced render, it puts a much greater load on the CPU as it's rendering every frame at full resolution back to the disk. It is also under these types of renders that FCP is able to utilize more than two cores (especially when working with ProRes), which is why you're seeing it jump your CPU history in activity monitor on the 8-core.

Quote

Part 1- FCP does heavily leverage the GPU on any realtime effects that FCP offers.
Part-2- non-real-time rendering uses the CPU.

Final Cut Pro's reliance on the GPU is limited solely to the ability of the card to play back video content effectively, which is why pretty much any GPU that's quartz extreme compatible will work in FCP. This includes any mac-compatible AGP, PCIe, or even integrated GPU (GMA950) that's been made in the last 4 years. The point I'm making here is that there is no GPU hardware accelleration happening at all inside of FCP (with the previously mentioned FXPlug exception).

It will be interesting to see how Apple evolves FCP once OpenCL is available as part of SnowLeopard. GPU accelleration in FCP could potentially lead to significant improvements in features that have as yet eluded the app, such as true background rendering.