MozillaZine's ChromeZone Now Open!

Monday May 24th, 1999

Steve Morrison, creator of the XULTool, has joined MozillaZine (as some of you may already know). He has been hard at work getting the XULTool working on our site, and we're pleased to announce that the ChromeZone is now online.

Now, with a simple form, you can change the look and feel of Mozilla, and create your own themes! You can also choose from some ready-made themes we have available. You can also send your own themes to ChromeZone for addition to our site.

So, fire up apprunner and head over to the chromeZone.

We got a lot of great entries for our little "name our new chrome area" contest, but in our final vote, "ChromeZone" came out on top. A number of people submitted the name "ChromeZone" or a variation for our contest. Clayton Scott was the first, however, and his prize is a stuffed Mozilla doll from Netscape. I know we didn't promise any prizes for the contest, but we wanted to give something to the winner.

Thanks to everyone for you contributions, and if you have any suggestions for the chromeZone, let us know.

#116 Re:MozillaZine's ChromeZone Now Open!

by David Hyatt <>

Wednesday May 26th, 1999 3:08 PM

You are replying to this message

Those of you who are complaining about XUL's speed and using the current builds as an example could use a basic lesson in the realities of software development.

XUL is an unoptimized content model being built on top of an unoptimized layout engine. There are many obvious known performance problems that will be addressed, but right now the focus is on features and not on performance and polish. It is too early in XUL's development cycle to be worrying about full-blown optimizations or making the UI look just right.

Gecko has now reached the point where they are focusing on optimizations and performance, namely incremental reflow, and you're going to see a lot of XUL speed increases as they fine-tune the layout engine.

Eventually XUL will get far enough along that we won't be overloaded designing features, and then we'll be able to work on optimizing the RDF-based content model that XUL is using. Some of this work is already taking place (we're able to at least grab for the low-hanging fruit as we continue to work on features).

If you need specific examples of obvious performance optimizations that will happen before we ship, I can give them to you now.

(1) The front end frames (the visual objects that correspond to nodes in the content model) aren't hashed, and so any time the content model changes and the frame tree needs to be updated, Gecko does a depth-first search of the frame tree looking for the frame that corresponds to the content node.

A hash table in this function (GetPrimaryFrameFor) will bring a big speed increase.

(2) Gecko's incremental reflow has no notion of batching, so an individual reflow command is generated for every individual change to the content model. This results in many more repaints/reflows than are necessary.

(3) Incremental reflow currently causes a repaint of the entire window.

The UI is perceived as sluggish because too many repaints are currently happening. At one point early on, we cheated and hacked in something to prevent the repaint of the whole window, and the UI became fast and responsive.

This will be fixed.

(4) The RDF/XUL content model is notifying the front end way too many times when it builds nodes (causing the front end to do a lot more thrashing than necessary). We're sending out notifications even before we've added the nodes into the content tree.

(5) The tree widget has been accused of being ugly and slow. Of course it is. Nobody is worrying about making it pretty yet. That can come later. As for it being slow, there are also many obvious huge improvements that can be made to the tree's speed. Right now, the priority is on making the tree widget WORK. Then, once its basic functionality is in place, we can worry about honing its speed. This is true of many of the other widgets in XUL as well.

I could keep going for pages and pages. Just remember that you're looking at a pre-alpha product, one that has not been optimized at all, and you should not be making the assumption that "an XML-based UI" is slow simply based on what you're seeing in a pre-alpha milestone build.

The visual look you're seeing in apprunner also isn't the final or real UI design for the Netscape product. It's just a toy that enables us to see what we're doing as we develop. There are plenty of talented UI designers that can take XUL and make beautiful and elegant UIs, and rest assured that they will. We don't have the time or luxury to be worrying about that right now in apprunner though.

Feature work first. Polish later. It will come together. You just have to have a little faith.