Chimera Not Dead EitherTuesday January 21st, 2003Yesterday, Chimera lead Mike Pinkerton posted a weblog entry in which he said that he was considering ceasing Chimera development. This lead to a Mac media frenzy, with stories at MacSlash and Slashdot. In a new blog post today, Pink has clarified the situation: Chimera is still alive. Mike, who would like to point out that he is not the only developer, was just having a bad day and the project will continue on its quest to make a browser that sucks less. This is more good news. I think there has been a slight overreaction in the Mozilla community to Apple's decision to not go with Gecko. The point is this: we don't need Apple's stamp of approval to know that we already have the best web browser. We don't need them to improve on what we've already done. The KHTML product is good for what it is, but we have a big lead in the important areas, like rendering. Yes, when we look in the mirror, we could be doing better in terms of stability, performance, and footprint. Even as AOL-TW's support has, for the time being at least, been reduced, improvements to Mozilla in the necessary areas remain very much achievable. The Mozilla 1.3 beta series is looking very good in the preview nightlies. A number of ticky-tack bugs and a few serious ones still have to be fixed, but it's clear to me that 1.3 is on track to be a tremendous release, the best Mozilla yet by a good measure. Products like Chimera and Phoenix will also continue to see improvements to their already solid foundations, even as they are technically in beta. I continue to be very optimistic about the whole Mozilla project. Things are definitely still moving in the right direction. Why wouldn't there be an overaction? Steve Jobs rips off from the Mozilla community, put the stuff he got into Safari, then starts lying about how much faster it is compared to any Gecko-based release out there. We could care less about this guy wanting to go with an Apple OS-specific browser solution for Apple computers. Whoopie!! Hell, he could claim it was the best thing for the Apple computer since holes in Swiss cheese were invented. Talking smack, making up bogus claims, charts & information and posting them on their web site as "fact," though, is another story. If that guy doesn't have anything good to say about Mozilla, then he should keep his damn mouth shut. [i]Steve Jobs rips off from the Mozilla community, put the stuff he got into Safari,[/i] Apple didn't use (er "rip off") anything from Mozilla in Safari, Apple used the KHTML engine... Which is what all this stink is about... Safari's UI? It's just a coincidence it looks a hell of a lot like Phoenix's? I'm not the only one who's noticed it, either (I wonder if that's due to those disgruntled, ex-Netscape employees that Stevie has working on that whole thing?) I first learned about it from somebody else on the message board just after Stevie's phoney baloney dog-n-pony show. But, again, I could care less about what Stevie & his friends do. All this stuff won't save the company. It's barely holding on to it's 3% market share, and nobody's got the money (except the Donald Trumps of the world) to get one of his iMac's. Keep shooting that mouth of yours off, Stevie. Your foot will only end up getting stuck in it, and I'm going to love seeing that. "But, again, I could care less about what Stevie & his friends do" Then please shut up. Don't you realize that you're the only one having a problem with Safari/Apple/Jobs and that your continious ranting is regarded pointless by almost anyone on Mozillazine. > Apple didn't use (er "rip off") anything from Mozilla in Safari In fact, Safari uses one of Gecko's most complex components - the view manager, because it's so much better than anything else. Check the credits carefully. Gerv From the safari "Acknowlegements": Netscape Communications Corporation ( arena files ) Copyright © 1998-2000 Netscape Communications Corporation. For khtml/misc/arena.[h|cpp], other contributors are: Nick Blievers <nickb@adac el.com.au>; Jeff Hostetler <jeff@nerdone.com>; Tom Rini <trini@kernel.crashing. org>; Raffaele Sena <raff@netwinder.org. For khtml/rendering/render_layer.[h|cpp], other contributors are: Robert O'Call ahan <roc+@cs.cmu.edu>; David Baron <dbaron@fas.harvard.edu>; Christian Biesinge r <cbiesinger@web.de>; Randall Jesup <rjesup@wgate.com>; Roland Mainz <roland.ma inz@informatik.med.uni-giessen.de>; Josh Soref <timeless@mac.com>; Boris Zbarsky <bzbarsky@mit.edu>. This library is free software; you can redistribute it and/or modify it under th e terms of the GNU Lesser General Public License as published by the Free Softwa re Foundation; either version 2.1 of the License, http://www.fsf.org/copyleft/le sser.html, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along w ith this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. Alternatively, the contents of this file may be used under the terms of either t he Mozilla Public License Version 1.1, found at http://www.mozilla.org/MPL/ (the  âMPLâ) or the GNU General Public License Version 2.0, found at http://www.fsf.org/ copyleft/gpl.html (the "GPL"), in which case the provisions of the MPL or the GP L are applicable instead of those above. If you wish to allow use of your versio n of this file only under the terms of one of those two licenses (the MPL or the GPL) and not to allow others to use your version of this file under the LGPL, i ndicate your decision by deleting the provisions above and replace them with the n otice and other provisions required by the MPL or the GPL, as the case may be. I f you do not delete the provisions above, a recipient may use your version of th is file under any of the LGPL, the MPL or the GPL. I will don't think there will have been enough reaction until most or all Mozilla resources are dedicated to Gecko, K-meleon, Chimera and whatever the *nix equivalent is (i.e., drops mail, news, compose, chat, etc.). (For some reason we're talking about windows browsers in this thread, but hey) You know, fact is, in terms of interface (which, you know, is what I actually spend my time using) Mozilla is my favourite browser. In terms of speed it loads fast enough and it loads Web pages fast enough. there's no significant difference with other browsers. (there might be if i loaded my web browser 20 times a day. i don't). Phoenix is ok too (configurable toolbars = good idea, sure), but needs improvement - well that's why it is 0.something right now. K-meleon is a horrific piece of crap. If I wanted to use it I'd just use IE only somehow with a new 'make the interface worse' plugin. (Ok, page rendering is better, but that's it.) People have to get off this 'bloat' kick. I don't use mozilla email. i don't use mozilla news. I certainly don't use chatzilla, which is godawful. How much does it matter that these unnecessary (for me) programs are included in my web browser? NOT ONE BIT. Not at all. I don't care. Ever. Fact is the web browser uses what - maybe 25 MB (of actual memory, plus maybe another 25 in VM) when you've got a bunch of windows open? Who cares? Out of a reasonable minimum, say 128 MB, that's not a huge proportion. (If you have less than 128 MB then trust me, you're in a tiny minority, and you're a problem that's going to go away as you upgrade.) Though obviously it's important not to let these things get totally out of control, and download size remains an issue while people still have modems ((So for example a phoenix-style architecture based on plugins so that people who want the web development tools, like me, can have them but others can save a few hundred kb download by not having them, is a good idea)), in general if you are thinking about putting a lot of effort into making code smaller it's *much* better to spend time dealing with problems that will remain or get worse in future - e.g. usability problems - than with problems that are already small and will vanish in future - e.g. memory usage. --sam If they're going to allow third-party downloads through Software Update, then there should be a mechanism to allow third-party applications to be provided with the OS - especially open source ones. /Applications/Extras or something like that... So even though Safari doesn't use Gecko, it still incorperates some other things? That's interesting "some other things"? Like what? I mean, what are you referring to? "Like what? I mean, what are you referring to?" The View Manager. Whatever that does. Alex I'm not a developer but I've watched a few of the techtalks on how Gecko works, so I'll take a quick stab at explaining it. All the cool stuff with fixed positioning, z-index, opacity, etc. that Mozilla can do is the result of a sophisticated View Manager. To see where the View Manager fits in it's probably helpful to have a basic overview of Gecko. I'm no expert and I've probably got some of this wrong but here's how I think a page get's to your eyes and what part of that is covered by the View Manager. First some chunk of data comes to the app from the network (or file). That's handled by Necko. That data, on its way to the screen, gets pumped through the different machines that make up Gecko. The first machine in its journey is the HTML Parser. The Parser takes that data from Necko and tokenizes it -- finds out where the tags are, where the text is, and does some buffering and a bit of cleanup on the data if it's not well-formed. Then the Parser passes it to the Content Sink. The Content Sink pulls in both the output of the HTML Parser and the style rules that were the result of CSS Parser's work. The Content Sink does some cleanup and arranges all of that parsed data into a logical tree. That gives you your content model -- the DOM tree. With this tree, Gecko can start to create formatting objects that can be used to house the content. Creating these formating objects, which have both stylistic data and content data associated with them, is done by the Frame Constructor. The Frame Constructor creates a Frame Tree. The Frame Tree is similar to the DOM tree but instead of establishing the logical relationship between the different elements of the document, it figures out everything about how the geometry of all the elements all fits together. It determines all of this geometry from the CSS rules and the logical relationships between the different DOM elements. The result of all of this is that Gecko has rectangles of content to lay out (not yet to the screen). But Gecko doesn't do a complete layout in one fell swoop. It gets some data from the network via Necko and pumps that chunk through this system. When we get more data from the network, it has to incorporate that data into the already processed data. A process called Reflow merges the new data into the existing data. Reflow looks a the geometry constraints imposed by the parent elements on their children (and I think in some cases the needs of the children are pushed up through the parent objects to Reflow) and computes all of this over and over as we get more data and need to adjust the geometry of any of those elements. So when we've got all of these Frames, rectangles of content, computed then we've got to put it on the screen. This is where the View Manager comes in. The View manager figures out where on the screen the data will be displayed, handling all of the positioning, sizing, depth sorting of overlapping Frames, transparency and translucency. When changes need to be made to areas displayed on the screen, the View Manager figures out which areas need to be repainted, the minimum area and that can be repainted and tries to minimize the frequency of those repaints. I've definitely omitted a lot and I'm probably wrong about some of this but that's roughly how bits from the network turn into formatted text and images on your screen. As you can see, the View Manager plays a key role in the process and is an area where performance and efficiency is very importatnt. That Apple used this critical piece of Mozilla code is a credit to Robert O'Callahan and all the others that worked in this area. --Asa |