From his Living Photoshop Adobe Blog, Photoshop engineer Scott Byer had this to say regarding the switch to Universal Binary using Xcode.
By now you have probably figured out that we aren’t releasing Universal Binaries of our current application versions. If you haven’t, all you need to know is pretty explicitly spelled out here.
“But, c’mon”, I hear people saying, “Steve said it was just a recompile!” Or, “Back during the PowerPC transition, you guys released a patch!”
Well, this time is different. And I really wish it weren’t. But let me tell you how…
When that original PowerPC transition was done, Apple did something clever. Very clever. The emulator that ran 68k code would recognize when it was calling out to PPC code, and would fiddle with things on the stack using the Universal Procedure calling vector. A lot of gobbledy gook meaning that a 68k binary could call out to PPC code that could then execute at native speeds. Well, for those that don’t know, Photoshop has a bunch of routines all tucked away to do the real heavy lifting – the bottlenecks. Most of Photoshop’s CPU time is spent in these routines. Even better, you can replace these routines using a plug-in. There’s the Multiprocessor extension plug-in, which replaces some routines with ones that know how to divide work up among multiple processors. And some which use the multimedia instruction sets that are available to varying degrees on different processors. And, in the case of the PPC transition, we could replace them with PPC native versions. With a plug-in, Photoshop could get a majority of the speed up as if it were a fully native application, but – and it’s a key point here – without having to recompile the vast majority of the Photoshop code, along with the resulting testing hit, mounds of debugging, and everything else that would imply. Most of the gain with a fraction of the cost, it made sense to do a mid-cycle update consisting, essentially, of that plug-in.
Doing that this time around was just not possible for a variety of reasons. It means is that this time, there’s no limited-cost option for getting most of the performance available on the platform for Photoshop in a short amount of time. In other words, no shortcuts.
That leaves doing the work for real – taking the whole application over into XCode and recompiling as a Universal Binary. And that’s no small task. You see, as software has matured so have the development environments we’ve used – Visual Studio and Metrowerks – they’ve adapted to handle the ever-growing applications using them. From having projects with large numbers of files that open quickly, to having compact debugging information, to having stable project formats that are text-merge-able in a source control system. These are things XCode is playing catch-up on. Now, Apple is doing an amazing job at catching up rapidly, but the truth is we don’t yet have a shipping XCode in hand that handles a large application well. And switching compilers always involves more work than you would think in a codebase of this size.
Now, I’m an engineer, and I’m all for getting products out in front of customers so they can use their machines to their fullest as soon as possible, but there is just no way putting out a Universal Binary of Photoshop CS2 would make any sort of sense. If you think about switching tool sets, with the resulting huge amount of work for both engineering and quality engineering, if you think about how far past the Photoshop CS2 release we already are, and if you include not having the workstation-class machines ready yet, I think you’d have to agree – far better to focus on making sure Photoshop CS3 is able to absolutely squeeze every ounce of power out of what I’m sure will be pretty spankin’ Intel-based towers by that point than to do tons of work moving an old code base to new tools.
-Scott
