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.

Whatipu

So far during our time back in NZ we haven't had much chance to get out of the city --- which is a bit of a shame because there are so many amazing places to enjoy. We've been up north to Omaha and the Bay of Islands, and to Rangitoto, and I went down to Hamilton for a Linux User's Group talk, and that's it.

We had some free time on Sunday so we decided to go out to the west coast. Auckland is nestled between the Waitemata Harbour coming in from the east and the Manakau Harbour coming in from the west, but it's mainly built up along the east coast. It's always fun to take a drive out west, across the Waitakere hills (a very large and lovely regional park) to the west coast beaches. Due to their relative remoteness and the pounding of the Tasman Sea, these beaches have a wild character that is very refreshing. (The move THE PIANO had a memorable scene of a settler's piano being dumped on a beach --- it was filmed at one of these beaches.) Although these beaches seem remote they're only about an hour's drive from the city (depending on how fast you can take the narrow winding roads through the hills!).

Whatipu itself is a huge sandy area just north of the entrance to the Manakau harbour --- windswept, barren and with very little development. The only access is an unsealed road around the southern edge of the Waitakeres. Although it's winter, it was a clear warm day and there were a couple of dozen cars parked at the end of the road by the time we got there about 3pm. We had a lovely walk along the black ironsand paths, through the wetlands to the beach. The tide was very high so there was no way to walk around to the largest part of the beach, but it was great just to stand there and feel the wind, the sun and the sea, watch the waves break on sandbars and admire the fortitude of the fishing-boat crews as they punched their way out to sea.

It's definitely one of my favourite places. There are a lot of bush walks on that side of the Waitakere hills and I hope we can go out there again to do some of them. But the trip also whetted my appetite to go in other directions. It's easy to live our daily lives here in the city and forget the wonders on our doorstep. In particular I hope we can soon get away for a weekend in the central North Island, which has always fascinated me with its lakes, mighty volcanoes and geothermal displays.

Update! I'm told that the rock at the entrance to the Manukau harbour is called the Ninepin Rock. The object on it is a navigation light, number 4107. 4 white flashes every 30 seconds. And it used to be serviced by my grandfather when he worked for the Auckland Harbour Board!

EU Patent Law Defeated

The European Parliament tossed out the proposed law that would have enshrined software patents. This is a huge victory that I did not expect.

Some argue that this is not actually a victory for those opposed to software patents:

Dr John Collins, a partner at patent attorney Marks & Clerk said the decision was not a victory for opoonents of software patents.

"Today's outcome is a continuation of inconsistency and uncertainty with regard to software patenting across the EU," he said.

"Software will continue to be patented in Europe as it has been for the last 30 years," said Dr Collins.

He's right in some ways. The Parliament was likely to add new amendments restricting the scope of software patents --- amendments that could not have been deleted again by the EU Council --- and the law's corporate sponsors decided that they prefer the status quo to the amended law. But if you look at those sponsors who supported the law and effectively wrote the original text, and the anti-democratic manner in which amendments to restrict patent scope were removed by the Council, I think it's very clear that overall, no law is better than their law, and their defeat is an important victory.

I don't know who writes Blooomberg's copy but it's quite sinister:

The European Parliament rejected a law on patents for software, ending a three-year effort by companies including Nokia Oyj and Siemens AG to counter U.S. domination of Europe's $60 billion market.

This is someone's spin repeated as fact. Software patents would never have helped anyone counter US domination of the software industry. Software patents protect incumbents and therefore the status quo. A nascent competitor who tried to assert patent claims against an incumbent would be buried in countersuits, and the deepest pockets and the largest patent portfolios would win.

As I've written before, the only way for non-incumbents to use the patent system to their advantage is to abandon the software business and become a pure patent company whose business is suing others. This might bring revenue into the EU, but it wouldn't alter US domination of the software industry (except perhaps by driving the entire industry into the ground). And it doesn't even require software patents in the EU; a European company could just as easily obtain US patents and pursue lawsuits there.

Anyway, it'll be interesting to see what happens next. Unexpected turnarounds like this make me suspect God is interested in this stuff after all :-).

Eclipse CDT

Eclipse 3.1 is out. Eclipse is an IDE framework written in Java and includes a Java IDE that is incredibly powerful. It also has amazing CVS integration. And it's open source, cross platform, has industry support, huge plugin community etc etc. I used Eclipse a lot when I was working on Java code and it was fantastic then ... it's even better now with full Java 1.5 support and lots of new features. On my machine at work it just flies --- I suspect due to a combination of performance improvements in Eclipse, improvements in JVMs, and the power of this machine. If you're writing Java code, there is no reason to not use Eclipse or something of similar power.

Unfortunately I don't work with Java right now, so I took the C/C++ tools for a spin. These tools are called the CDT, now at version 3.0. The CDT feature set is pretty good for a C++ environment --- intelligent (parse-tree based) code completion, intelligent navigation and searching, debugger integration, on the fly builds, and basic rename refactoring. This is very impressive given the nightmarish world of C and C++ parsing and semantics. I'd love to be able to use the CDT to work on Mozilla ... I currently use emacs, which I detest.

The problem is that Mozilla is a huge and complicated codebase. There are more than 4,500 C++ files and 1,700 C files. The build process is complex, and generates a lot of code from IDL in our own special way. This creates two major problems for tools: scaling performance and making sense of the codebase. Last time I tried the CDT (2.1) it just collapsed. The good news is that CDT 3.0 is much better, perhaps partly due to improvements in Eclipse itself and my improved hardware. There's now a built-in tool that reads the 'make' output from a complete build and extracts all sorts of information useful to CDT --- include file paths, defined symbols, which source files are part of the build, and so on. Everything is also much more scalable now; I've actually been able to index most of Mozilla and get code completion and some other things working.

The bad news is that there are still showstopper problems. The make output scanner doesn't work reliably so some of my source files don't get the correct information. When I worked around that by hand, I was able to index most of the Mozilla code but code completion popups and navigation operations took 5-10 seconds to happen, which is unusable. In general while playing with the tools I kept getting into strange situations including hangs, out of memory situations, and runaway background tasks.

It's a real shame because the tools look so good and they seem so close to working --- much closer than six months ago. If a few bugs and glaring performance problems get fixed, I'll be able to throw away emacs and step up into a much more productive environment. I'm really looking forward to that.

It's important to remember that Mozilla is an extreme test, a particularly large and complicated project. No IDE has ever been usable on Mozilla (beyond basic text editing); if CDT gets there, it will be the first. For smaller and simpler projects --- i.e. most C/C++ projects --- the CDT probably works just fine.