Viro said:
That's quite unlikely nowadays, unless you're a major assembly guru and know the hardware really well. No offense meant if you're one of these gurus, just that for the majority of the population, the C++ compiler will generate much better code than they could possibly hope for.
The default compiler in VC++ is not aware of SIMD extensions, I've inlined Assembly instructions to make use of SSE/SSE2 extensions for speed ups. Prior versions of GCC don't make good enough use of Altivec, I did buy CodeWarrior 8 which has options to enable Altivec instructions. When in project builder, there's nothing to really indicate that the compiler will use AltiVec where it's available. We sort of "assume" that it's making the best optimizations possible. Further more, GCC and Project Builder creates binaries that should be able to run on various PPC chips, in this case both G3 and G4 CPUs. MCC is different in that you can target specific PPC CPU models for even more optimizations. I'm just not overly convinced that GCC is making use of Altivec. Granted the data set has to be organized in such a way that can be easily SIMD-ed, in which case I'd inline my Assembly code anyways right next to my C/C++ code.
Viro said:
Emulating widgets brings a lot of problems of its own. The first thing that comes to mind is that the widgets will look out of place. A Qt/Mac app looks really out of place on my Panther system. Some of the text are misaligned (vertically), and the theme looks more like Jaguar than Panther. Given that Panther has been out for half a year, its a shame that Qt hasn't been updated to reflect the changes.
I vaguely remember Qt/Mac 3.2 or 3.3 announced that brought it up-to-date with Panther. But you're right, it still looks out of place. But if you ask me, that brush metal look is what's out of place. I find that black text is very difficult to read when over the grey brushed metal windows, worst than having text over the pin stripes.
Viro said:
Speed is also going to be an issue since you aren't really using native widgets but drawing your own. Updates to native widgets will not be visible in your custom drawn widgets.
Not necessarily. Native widgets still use Quartz to do the drawing, compositing, then it gets shipped down the pipeline where hardware acceleration kicks in for alpha blending, scaling, etc. Qt/Mac uses Quartz to draw their custom widgets and then that image gets passed along the pipeline just like the native widgets.
From my perspective after using Qt/Mac, Carbon and Cocoa, Qt/Mac is about on par with Carbon based apps where UI speed/responsiveness is concerned. There is one thing I do like about Qt/Mac over Carbon though: in some rare situations Carbon apps will not render text with anti-aliasing. Example: I was using OSX 10.2 and Dreamweaver MX, which I believe it to be using Carbon. All the text in that app was non AA which bothered me (until I discovered Silk). I think the reason for that is because there's 2 flavors of Carbon. One reserved for backwards compatibility with older MacOS, and a newer Carbon that takes advantage of new features in OSX. Macromedia opted for compatibility so Dreamweaver MX lacked new features found in OSX.
Qt/Mac uses their own font AA to render their text. This alleviates the worry of the underlying Carbon font rendering.
