Adobe Photoshop engineer details Intel Mac challenges
A software engineer working on Adobe Photoshop says the company's decision not to deliver native Intel Mac support until the next major release of its high-end graphics suite is a result of the enormous task associated with switching to Apple Computer's Xcode development environment.
Last month, Adobe chief executive Bruce Chizen stated that Creative Suite 3 -- which will include the next major releases of Photoshop, Illustrator, InDesign, GoLive and Acrobat -- will not be available until the second quarter of 2007.
"When that original [68K to] PowerPC transition was done, Apple did something clever. Very clever," Adobe engineer Scott Byer wrote in a posting on his Web site. "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."
This enabled Adobe to replace many of its 68k "heavy lifting" routines with PPC native versions through plug-ins that were distributed to customers.
"With a plug-in, Photoshop [was able to] 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," Byer wrote. "Doing that this time around was just not possible for a variety of reasons."
In order for developers to properly build a Universal Binary -- a version of an application that will run natively on both PowerPC and Intel Macs -- they'll need to transition their application's codebase to Apple's Xcode development environment. [What this] 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" Byer wrote. "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," Byer continued.Â*"And that's no small task."
Since Apple's Xcode is a relatively new development environment, it had previously been unsuitable for use in the development of extremely large projects with large numbers of files that open quickly, Byer explained. So instead, Adobe has so far relied on development environments from Visual Studio and Metroworks, which also feature more compact debugging information and more stable project formats that are text-merge-able in a source control system.Â*
"These are things XCode is playing catch-up on," said Byer. "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."
It wouldn't "make any sort of sense" for Adobe to release a Universal Binary of Photoshop CS2, the current version of the company's software suite, the engineer contends.
"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," Byer wrote. "[It's] 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."
Last month, Adobe chief executive Bruce Chizen stated that Creative Suite 3 -- which will include the next major releases of Photoshop, Illustrator, InDesign, GoLive and Acrobat -- will not be available until the second quarter of 2007.
"When that original [68K to] PowerPC transition was done, Apple did something clever. Very clever," Adobe engineer Scott Byer wrote in a posting on his Web site. "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."
This enabled Adobe to replace many of its 68k "heavy lifting" routines with PPC native versions through plug-ins that were distributed to customers.
"With a plug-in, Photoshop [was able to] 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," Byer wrote. "Doing that this time around was just not possible for a variety of reasons."
In order for developers to properly build a Universal Binary -- a version of an application that will run natively on both PowerPC and Intel Macs -- they'll need to transition their application's codebase to Apple's Xcode development environment. [What this] 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" Byer wrote. "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," Byer continued.Â*"And that's no small task."
Since Apple's Xcode is a relatively new development environment, it had previously been unsuitable for use in the development of extremely large projects with large numbers of files that open quickly, Byer explained. So instead, Adobe has so far relied on development environments from Visual Studio and Metroworks, which also feature more compact debugging information and more stable project formats that are text-merge-able in a source control system.Â*
"These are things XCode is playing catch-up on," said Byer. "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."
It wouldn't "make any sort of sense" for Adobe to release a Universal Binary of Photoshop CS2, the current version of the company's software suite, the engineer contends.
"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," Byer wrote. "[It's] 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."
Comments
I've quoted this article almost a week ago in our own threads.
I'll post the link again, with the related one.
http://blogs.adobe.com/scottbyer/200...osh_and_t.html
http://blogs.msdn.com/rick_schaut/ar...24/560461.aspx
We've been having a rather heated discussion about this issue.
There are just a couple of people here who think Adobe is dragging their feet. I don't agree.
None of the other development software "people" have had the time NOR will they ever, they will need to spend a lot of time updating their libraries. Its no mean feat.
Originally posted by ChristoRogers
Does anyone know why you have to use Xcode to build a Universal Binary?
I've been wondering that too. It seems rather dumb to force developers to use one compiler to make universal apps.
Creating Universal Apps in itself is really easy though, and doesn't require Xcode. Specifically I have been porting a bunch of Unix apps to Intel recently and its painless to produce Universal apps.
Originally posted by dr_lha
The trouble is that a lot of big projects are written using Metrowerks Codewarrior. As that software is not longer supported and will never be updated to support compiling for Intel, devs have no choice but to move their packages to the only show in town now: Xcode.
Creating Universal Apps in itself is really easy though, and doesn't require Xcode. Specifically I have been porting a bunch of Unix apps to Intel recently and its painless to produce Universal apps.
Basic apps without a GUI or other specialized libraries and such may be easy, though, even then, you have to de-bug them, and test them. You still have to optimize them, if they require certain performance characteristics. Even worse, some code may be assembly. It's surprising how many programs have long assembly routines when speed is an issue. That all has to be coded by hand. Each Endian problem has to be found, by hand, and redone.
Even XCode doesn't do all of this.
Originally posted by bdkennedy1
So basically, instead of preparing for the future they saved everything until the last second. Instead of gradually, over time doing things the right way, they saved almost a total code re-write until the last second.
So, you didn't actually bother to pay attention to what was being said? Read the two links I posted, carefully. You should get a good idea for what is happening.
Originally posted by melgross
So, you didn't actually bother to pay attention to what was being said? Read the two links I posted, carefully. You should get a good idea for what is happening.
Come of it, who follows links?
i thought since then there have been other solutions to making universal binaries? i have no idea.... as an end user i have little in depth knowledge of this.
as much as i would like to see them shipping all universal apps, Adobe does seem to have a valid point though. the important points on their side are:
1) this is a big project for them to undertake, let them do it right
2) by the time they hack CS2 it will be almost time for CS3 anyway. why pull developers to patch "old" code instead of hastening the work on the next thing?
3) there are no Intel based towers available yet, and will the big customers jump on a potentially buggy Rev. A machine anyway? a lot of designers use towers for the horsepower, and they do not even exist yet.
4) the big companies that REALLY use Photoshop in a big way (and buy a ton of licenses) never jump to the newest software till they know it is pretty bug-free. remember how long it took those people to jump to OS X at all? they will want Intel towers and some solid proof the Intel based stuff works. bugs cost them time which means money.
when you look at it from their standpoint as developers and a bunch of managers looking at the business side of things..... it seems unfortunate, but reasonable. i'm sure a ton of Pro level users with Intel based Macs want their Photoshop right now, but they knew what they were getting into, and depending on how old the machine is they replaced they may still be effectively faster even running Rosetta. i know a new 20" iMac (or MAcBookPro) running Photoshop through Rosetta emulation would still be faster than on my G4 tower. when CS3 ships it will be a nice speed hop.
It only makes sense for Adobe to get it right before releasing CS3, but my guess is that it'll make it to market sooner than the quoted 2nd quarter of 2007. Can't you just see Adobe making a big splash announcement of CS3 availability at MacWorld in January?
Originally posted by crampy20
Come of it, who follows links?
If you don't carefully read the article, and won't follow the link to the actual blog, and the one expanding on it, then why post at all?
Most people do follow links, if they want to understand what is actually being said.
They also try to follow as much of the thread as possible before posting.
Originally posted by ficino
This isn't "inside" information, nor is it news. Shame on AppleInsider for publishing this as a story!
They never said it was "inside" information. Very few of the articles are. It's news, though not exactly new.
It's also information about a topic frequently debated on this site.
As such, it should have been published.
Originally posted by melgross
Basic apps without a GUI or other specialized libraries and such may be easy, though, even then, you have to de-bug them, and test them. You still have to optimize them, if they require certain performance characteristics. Even worse, some code may be assembly. It's surprising how many programs have long assembly routines when speed is an issue. That all has to be coded by hand. Each Endian problem has to be found, by hand, and redone.
Even XCode doesn't do all of this.
No doubt, and I wasn't saying that. I just meant, the actual creation of a Universal Binary itself is simple. Testing is a whole different matter.
I'm fully aware of Endian issues, one of the reasons I have a Mac in the first place is because it has the same Endian processor that the embedded system I work with has. Of course this has gone out of the window with Intel Macs!
The big houses have a major task ahead of them in migrating, but they simply have to, no other way about it. Metrowerks has, for all intents and purposes, vacated the Mac market, and other IDEs such as Eclipse, just don't do the Apple mambo quite right yet.
No developer can say, with a straight face, that they were caught off-guard by the need to move to Xcode. They may have been caught off-guard by the *strength* of that need, "OMG, you're *serious*?" but they can't say they weren't warned about it long ago.
Adobe has a valid point, however, that the IDE has needed maturation - which is kind of unfortunate, since it was actually a highly robust IDE, and considered state of the art... in 1996. They let it languish, and now they have to catch up. Which I think they're doing well, to be honest.
Adobe and the other big houses should have had a plan in place by this point though, to migrate portions as test cases. They really can't claim they were blind-sided... now Apple has to deliver the goods to make it viable.
Originally posted by Kickaha
Apple has been saying for, well, *years* that developers needed to move to Xcode... Cocoa preferred, Carbon if they needed to... but Xcode in any case.
The big houses have a major task ahead of them in migrating, but they simply have to, no other way about it. Metrowerks has, for all intents and purposes, vacated the Mac market, and other IDEs such as Eclipse, just don't do the Apple mambo quite right yet.
No developer can say, with a straight face, that they were caught off-guard by the need to move to Xcode. They may have been caught off-guard by the *strength* of that need, "OMG, you're *serious*?" but they can't say they weren't warned about it long ago.
Adobe has a valid point, however, that the IDE has needed maturation - which is kind of unfortunate, since it was actually a highly robust IDE, and considered state of the art... in 1996. They let it languish, and now they have to catch up. Which I think they're doing well, to be honest.
Adobe and the other big houses should have had a plan in place by this point though, to migrate portions as test cases. They really can't claim they were blind-sided... now Apple has to deliver the goods to make it viable.
This really is a serious issue.
But, the truth is that Apple never gave developers a good reason to switch over.
Every major developer I've spoken to has slammed Apple's toolset.
What people forget is that if it wasn't for MetroWorks, Apple might not be here today. And then, after they think they don't need them anymore, Apple tells people to leave them. That's not right either.
What Apple should have done was to help MetroWorks bring their software up to the requirements of moving to UV.
Are Apple developers benefiting from just having one set of tools? No way.
If Apple was hinting that developers would *need* to move to XCode, rather than saying that they wanted them to, it might have been different.
It also might have been different if Apple told their major developers before June 2005 that they were going x86.
MS does one thing right, it tells its partners (and even the public) where it's going long before it starts the work. Apple always waits until the last minute.
If anyone thinks that Apple wasn't working on getting most of its own programs UV'd long before June 2005, we have a bridge here in Brooklyn that you might want to look into.