Thursday 21 July 2005
Gecko 1.9
Within a week or two we'll be branching off 1.8 and opening the trunk for Gecko 1.9 development. This will be very exciting because we have a lot of interesting changes planned, many of which are underway and will land soon after the branch is cut. Here's a rundown of some of the upcoming changes:
I'm excited that these changes will simplify Gecko considerably. It's definitely something that needs to be done. Moving from four trees (content, frames, views, widgets) to just two (content and frames) should be a huge help. Eliminating most of our gfx code will also be a big win.
- The new Thebes graphics code will be landing. Thebes is a C++ wrapper around cairo. Very soon we should be able to produce Thebes-based Firefox builds for Linux and Windows. We'll be doing intensive development and testing of these builds during the 1.9 cycle until we reach the point where we can make them the default builds. This will give us a number of cool features:
- Much less graphics code for us to maintain --- most of the work will be in cairo, which is shared with many other projects
- Various options for accelerated graphics: Glitz on Windows and Linux, Quartz on Mac, XRender on Linux (with an accelerated X server such as Xglx or Exa)
- Better quality rendering: some antialiasing, bilinear image scaling
- A powerful new graphics API so we can draw fancier borders, draw rotated HTML, etc
- Fix various rendering bugs that are currently hard to fix
- Much less graphics code for us to maintain --- most of the work will be in cairo, which is shared with many other projects
- Blake Kaplan's caret patch fixes many issues with caret positioning and drawing by making caret drawing go through our standard paint path. In conjunction with the Thebes work, carets in rotated text boxes will be drawn correctly.
- We have a units patch from sharparrow which will simplify our code and make Gecko work intelligently on high-density displays. On 200dpi screens we'll draw 2x2 screen pixels for every CSS pixel.
- We also have an events refactoring patch from sharparrow that will simplify our code and fix a number of bugs. Some more events refactoring patches will follow to simplify the code even more.
- I have a plan to eliminate our widget trees by having all Gecko content render into one top-level widget whose only children are plugins. This will simplify our code considerably, fix some bugs and should improve performance (especiallly with Glitz).
- I also have a plan to eliminate the separate view trees we currently maintain and move the view manager's functionality in the presshell. This will also simplify our code a lot and will smooth the path to fixing various bugs (including at least one Acid2 bug).
- Christian Biesinger has a patch to fix some plugin architecture problems by moving plugin loading to content. This also fixes an Acid2 bug.
- I hope that David Baron's reflow refactoring branch can land as soon as possible too, which will fix many bugs and simplify our code some more.
- There is a plan to simplify the SVG code and reduce the footprint of SVG elements by being more intelligent about how we handle DOM SVG values.
I'm excited that these changes will simplify Gecko considerably. It's definitely something that needs to be done. Moving from four trees (content, frames, views, widgets) to just two (content and frames) should be a huge help. Eliminating most of our gfx code will also be a big win.
Comments
And they don't cause any regressions, off course? ;-)
I have not taken the time to understand the problem yet but just curious as you stated, "Fix various rendering bugs that are currently hard to fix"
and bug 9458 is one of them for sure.
Martijn: of course they'll cause regressions. And we'll fix them with your help :-)
Will this new graphics system work for them? With their integrated intel GPU's in there bland Dell systems. This is a rather large chunk of potential marketshare I hope we don't loose.
If you take a look at the roadmap: (http://www.mozilla.org/projects/firefox/roadmap.html)
You see when DPA1 and DPA2 were released, but it doesn't mention either 1.1beta nor the final 1.1. Why is that? Am I overlooking something?
Robert: that is a big issue we're thinking a lot about. Graphics performance on that sort of system is probably going to take a lot of our energy for the next year especially when doing SVG and other advanced effects. The good news is that we're not working on it alone; it's a cairo issue.
Will we see improvements in HTML pageload (Tp), XUL pageload (Txul) and startup (Ts) time?
Simon: hopefully!!
Those weak GPU's totally stink, but it is a large audience.
any place I can go to see if any of the other Target: Mozilla 2 features from the Mozilla wiki will be going in? http://wiki.mozilla.org/Mozilla2:Home_Page
I'm especially curious about things like Unified Storage, Docshell improvements, profile sharing/multiuser, and the improvements to libpr0n (JPEG2k and colour profiles).
If you can't answer, I truly understand, as you and the others are stupidly busy. Thanks for all your hard work.
--JM
I'm not really sure about those other Mozilla 2 features. There are plenty of other plans that I'm not aware of.
Cairo will have to be ported to OS/2 and BeOS. It should be relatively easy to get basic cairo running there --- more work to get acceleration going. I know people are already looking at it.
I'm looking forward for Gecko 1.9. It's always better to make it faster and faster and less buggier :).
It would be very handy to have a status update of Gecko features (about CSS 2.1, CSS 3.0 etc.) like the nice Status Pages for SVG: http://www.mozilla.org/projects/svg/status.html and Xforms: http://www.mozilla.org/projects/xforms/status.html
Does such a Page exist, if not, wouldn't it be a good idea?