07-27-08
|
#13 (permalink)
|
|
Networking Nut
Join Date: Aug 2006
Location: WA, USA
Posts: 646
Rep: 57 
Unique Rep: 54
|
Quote:
Originally Posted by Chipp
Actually, you code for a rendering engine rather than a browser. Since this runs Gecko (Firefox) and Trident (IE) pages coded for either should work fine.
|
and it's actually a bit mroe complicated for Mozilla:
Quote:
Firefox 3 for Mac OS X: Under the Hood
http://boomswaggerboom.wordpress.com...nder-the-hood/
Firefox 3 will be released soon (get the RC here). While the release contains a huge number of new features and performance improvements for all platforms, it is particularly significant for Mac OS X users. We rewrote most of the Mac OS X code that was behind Firefox 2 in order to benefit from modern Apple technologies and fix long-standing bugs. Once you try it I think you’ll agree that the results are astounding. I’d like to explain what exactly we did in this rewrite, how Firefox 3 for Mac OS X is different “under the hood.”
Before I start, I need to explain Gecko vs. Firefox for anyone who doesn’t already know. Gecko is the engine behind Firefox. It provides the capabilities that we use to build Firefox. Under the umbrella of Mozilla, Gecko is actually a much bigger project in technical terms than Firefox is. For example, there is much more Gecko code than there is code specific to Firefox, which is an application we built on top of Gecko. Firefox and Gecko have different version numbers - Firefox 2 uses Gecko 1.8.1 and Firefox 3 uses Gecko 1.9. This post is about changes we made in Gecko 1.9, the engine behind Firefox 3.
The biggest change is that Gecko 1.9 is based on Cocoa instead of Carbon on Mac OS X. There has always been a lot of confusion about what this means, particularly since Gecko 1.9 also happens to include Aqua form controls. It may seem strange to some, but Gecko’s new Cocoa underpinnings and its Aqua form controls are almost completely unrelated.
There are only 2 types of Cocoa objects at the heart of Gecko 1.9 on Mac OS X (let’s forget about the menu bar at the top of the screen for now). Cocoa’s NSWindow allows us to make and control a window on the screen and Cocoa’s NSView allows us to draw things into a window. Those two objects also allow us to get most of the events we need to know about from the operating system (such as key and mouse events). We do not use actual Cocoa buttons or any other Cocoa controls within any Gecko 1.9 windows. The context menus, dropdown menus, the toolbar, the search bar, the buttons and text fields within web pages - they are not actual Cocoa controls. For example, instead of using actual Cocoa buttons for “Submit” buttons we just draw the image of an Aqua “Submit” button into an NSView, one of the basic Cocoa objects we use. Gecko 1.9 has Aqua form controls because we now draw images of Aqua form controls when appropriate, not because we use actual Cocoa controls. The reason we don’t use actual Cocoa controls isn’t because we are lazy or we can’t figure out how to use them or because we are constrained by our cross-platform requirements - Apple’s WebKit doesn’t use actual Cocoa controls for things like “Submit” buttons or popup buttons in web pages either, at least not the last time I checked. IE for Windows is in the same boat. The reason Gecko 1.9 doesn’t use Cocoa controls is for the sake of flexibility - form control behavior and appearance can be changed significantly via HTML, CSS, and JavaScript. Actual Cocoa controls are simply not flexible enough to do all of the things that people want to be able to do with controls on the web.
So if we didn’t get Aqua form controls out of the deal why did we do the Cocoa rewrite? First of all, Apple has deprecated much of Carbon already1 and has made it clear that Cocoa is the future for Mac OS X applications. Apple is investing heavily in Cocoa, which benefits us if we use Cocoa. Cocoa also gives us access to great features that would be more difficult or impossible to take advantage of through Carbon. For example, with Cocoa we were able to relatively easily draw using CoreGraphics instead of the ancient Quickdraw API (more on this later). Secondly, the Cocoa way of doing things matches up with the Gecko way of doing things better than Carbon did. Our Cocoa code is easier to understand and maintain because of this2. This will result in faster development and fewer bugs in the long run. In fact, we actually added more capabilities to Firefox 3’s Gecko 1.9 (such as transparent windows, unified toolbar windows, and an alert service) than we have ever added in any release of Gecko since Firefox 1.0. This is in addition to doing a huge amount of work just to re-implement many of the features that Gecko 1.8.1 had already implemented in Carbon!
Another major under-the-hood change in Gecko 1.9 for Mac OS X is drawing via CoreGraphics and ATSUI instead of Quickdraw. Like much of Carbon, Quickdraw is deprecated and does not exist in 64-bit Mac OS X. Gecko 1.9 uses the Cairo library on all platforms, and Cairo draws with CoreGraphics and ATSUI on Mac OS X. The CoreGraphics drawing API is modern and hardware accelerated, a huge improvement over Quickdraw in terms of speed, capabilities, and code clarity. In addition to using CoreGraphics ourselves, we have made it possible for plugins to use CoreGraphics via NPAPI Drawing Models3. Flash is already prepared to take advantage of this new capability in Gecko 1.9! As for text, using ATSUI allowed us to improve our text kerning and ligature capabilities. It also gives us better glyph cluster positioning, which is good for Indic languages and languages that use exotic combining marks.
I hope this helps to shed some light on why Firefox 3 is a particularly significant upgrade for Mac OS X users. I’m really proud of what we accomplished with this release, it was ambitious and things worked out well. Kinks remain as with all major revisions, we’ll be addressing those quickly in minor updates to Firefox 3.
==
1 While the deprecated Carbon API is still available for 32-bit applications like Firefox 3, it simply won’t be available to 64-bit applications. Firefox 3 for Mac OS X will not be available in 64-bit but we’re preparing for 64-bit by removing code that won’t work in 64-bit.
2 It might be true that on the whole our Cocoa implementation is more complex than our Carbon implementation was, but that is because our Cocoa implementation does far more than our Carbon implementation ever did. The Cocoa code is still more readable and maintainable.
3 See the NPAPI Drawing Models spec. http://wiki.mozilla.org/Mac:NPAPI_Drawing_Models
|
CPU
Intel E5405 Xeon (x2) |
Motherboard
Supermicro X7DAE+ |
Memory
Micron 8GB (2x4GB FB) |
Graphics Card
Asus 3870 X2 1GB |
Hard Drive
2x Seagate 1.5TB, RAID-1 |
Power Supply
CM RS900 |
Case
U2-UFO Horizon |
CPU cooling
Thermalright HR-01 X |
OS
Windows Vista x64 |
|
|
|
[techPowerUp!]Sleipnir Browser plans to take on IE and Firefox
