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:


  • 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

  • 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.


23 comments:

  1. Simplifying code, architectural improvements, fixing whole classes of bugs... its enough to make me drool! I hope to find the time to seriously start learning Mozilla so I can help with the coding. BWT, Roc, have you considered listing your blog on Gemal's Blogupdates, http://gemal.dk/mozilla/blogupdates.html ?

    ReplyDelete
  2. Sounds great, all these changes.
    And they don't cause any regressions, off course? ;-)

    ReplyDelete
  3. Will any of this have an effect on [Bug 9458] Implement inline-block in layout.
    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.

    ReplyDelete
  4. steve england22 July 2005 00:19

    all this sounds awesome. can't wait!

    ReplyDelete
  5. Robert O'Callahan22 July 2005 00:50

    Arthur: David's reflow refactoring is the key to that one.
    Martijn: of course they'll cause regressions. And we'll fix them with your help :-)

    ReplyDelete
  6. All I can say is wow! I really can't imagine the kinds of cool stuff that people will do with Cairo. But I wonder what the timeline will look like. If Gecko 1.9 can land in Firefox 2.0 by early-to-mid next year then it should be able to take some of IE7's heat. I have a feeling people are going to be dissapointed with IE7, and with Longhorn for that matter.

    ReplyDelete
  7. I'm personally curious about performance. If Asa's right, there's a huge market in coming months of older Win 2k users who will want a better browser (and IE 7.0 is XP only). This is potentially a huge chunk of the corporate market. Lots of systems, some lower end.
    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.

    ReplyDelete
  8. I don't know if I should post this here, but here goes:
    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?

    ReplyDelete
  9. Robert O'Callahan22 July 2005 09:18

    miguel: we don't know exactly what the timeline will look like, but I'm hoping we'll ship something as soon as the graphics work is done even if it means pushing off other Gecko work or Firefox features.
    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.

    ReplyDelete
  10. Robin - see http://supernova00.biz/blog/2005/07/firefox-11-scraped-will-be-15.html

    ReplyDelete
  11. Will the Thebes landing include changing to cairo for printing?

    ReplyDelete
  12. Simon Paquet22 July 2005 14:29

    Robert, this sounds really cool. Will all that refactoring and simplification work also reduce the code size of gecko code in FF/TB/SB/SM?
    Will we see improvements in HTML pageload (Tp), XUL pageload (Txul) and startup (Ts) time?

    ReplyDelete
  13. Robert O'Callahan22 July 2005 17:02

    john: yes, that's the plan. No work has been done it yet on our side, but on the cairo side there are some great people working on Postscript and PDF output.
    Simon: hopefully!!

    ReplyDelete
  14. ROC, you mentioned that the powerful new graphics API will allow us to draw fancier borders. I'm unsure what that might look like, could you give an example?

    ReplyDelete
  15. Robert O'Callahan22 July 2005 17:34

    Well, dotted borders could use antialiased circles instead of squares, and rounded borders could have the rounded edges antialiased.

    ReplyDelete
  16. @roc: great, just wanted to make sure that segment isn't forgotten. It would be a mistake to ignore it. Those GPU challeneged systems are manufactured in bulk and deployed in batches by the thousands. There are easily millions of them in existance. Most running win2k and IE 5.5 or IE 6. All potential converts.
    Those weak GPU's totally stink, but it is a large audience.

    ReplyDelete
  17. Heck, there are folks still using old machines with no 3D accelerators at all, like my mom who I installed Firefox for, and my ghetto box in the bedroom :)

    ReplyDelete
  18. Holy buckets, Gecko 1.9 sounds more like Gecko 2.0 with all the architectural improvements going in! I mean, all Cairo with C++ wrappers for graphics, major improvements to layout and rendering, bugfixes for the ages, and long needed cleanups and refactorings. I mean, wow, seriously!
    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

    ReplyDelete
  19. How about OS/2 and/or BeOS? Cairo is not ported to these platforms...

    ReplyDelete
  20. Robert O'Callahan26 July 2005 21:40

    Some time during the 1.9 cycle we may indeed start calling it Gecko 2.0.
    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.

    ReplyDelete
  21. Awesome guys!
    I'm looking forward for Gecko 1.9. It's always better to make it faster and faster and less buggier :).

    ReplyDelete
  22. Dysfunksional.Monkey4 August 2005 15:33

    Does anyone know where I could find a quick run-down on what CSS3 features Gecko1.9 supports? I've just learned that Safari handles the CSS3 background spec, which is stunning

    ReplyDelete
  23. Not only features in upcoming Gecko 1.9 would be interesting, but also those in existing Gecko 1.8!
    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?

    ReplyDelete