Chimera Not Dead Either

Tuesday January 21st, 2003

Yesterday, 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.

#17 Safari uses the Mozilla View Manager which ...

by asa <>

Thursday January 23rd, 2003 9:15 PM

You are replying to this message

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.