|Mariner and NGLayout : Why do both?|
We all believe that NGLayout will replace the current layout sources, sometime around the end of this year. Until then, though, there is much that can still be squeezed out of the existing layout engine. NGLayout will not be ready to be included into the mozilla source by the time we want to release 5.0, so we've got at least another major (and probably several maintenance) releases which will use the current layout engine.
Mariner is the code name for performance and stability enhancements to the layout/layers/style sheet code. The project changes the layout engine to make the document model persist across resizes; so, each resize in Mozilla causes a page reflow instead of a reload from the cache. Now that we have a persistent document model, we are working on implementing a DOM interface to it.
Mariner includes a lot of performance enhancements, mainly in three areas:
- Text layout: The algorithm used to find break positions within text was improved. Also, the break positions were stored in a break table that gets consulted for doing text reflow.
- Table layout: In table layout, each cell gets laid out onto a rectangle of infinite width/height in the first pass. Then, once all the minimum and maximum widths/heights of cells have been figured out, a second pass of table layout occurs that lays out each cell's contents into a bounded rectangle. In 4.0, the second pass of table layout would reparse and relayout the cell from the HTML tags contained within the cell. In mozilla, because of Mariner's persistent document model, the second pass iterates over the model and adjusts the position and dimensions of the cell's content to fit in the bounded rectangle. All the malloc overhead incurred in the first pass for creating the document model is not incurred in the second pass. This make overall table layout much faster.
- Resize/Reflow: Since resizes cause a page reflow rather than a reload from the cache, they are much faster.
Many bugs related to resizing pages that have dynamic content on them are fixed.
Our current goal is to implement enough of the W3C spec to enable content developers to do what they want to do now. Work is underway to make the DOM tree the authoritative source of all style and attribute data. This will allow all HTML attributes to be reflected (read and hopefully write) into the Level 1 DOM. We'll make as many of these meaningfully mutable as possible. If you'd like a quick hack, you can add appropriate mutation of your favourite element or property. Some of this work will probably also make style sheets much better, as a nice side-effect.
|You can help (please :)|
Please send mail to the addresses at the top of the page - we need people that aren't afraid to get their hands dirty working with some (admittedly) convoluted code. Help in multibyte text layout would be wonderful, and anyone willing to work on the DOM would be welcome as well.
Given that there are only two of us (with a third and fourth working on CSS and one lazy slacker doing DOM work for XML and HTML) there is plenty of room for others to help out and make a difference in the stability, performance, and feature set of 5.0.