Hard to believe two months have gone by at Mozilla since I joined. Mozilla is undergoing a lot of change right now because we’re pushing out Firefox 4,hiring like crazy and transitioning to a rapid release cycle so keeping up with the change and learning everything has kept me busy.
The general openness has been great, I only go to one regular multi-person meeting that isn’t public. Some of the interesting teams/people/projects have I been working with are:
The graphics module in Mozilla is responsible for getting the bits on the screen. With Firefox 4 this uses the layers system. There are 5 main layer types:
- Container – only holds other layers
- Image – image data
- Color – single color
- Canvas – HTML canvas
- Thebes – thebes surface (thebes is the Mozilla drawing API, it maps onto cairo for its implementation)
There are also a couple of specialized layers: Shadow (a proxy to the “real” layer somewhere else) and Readback (to handle windowless plugins properly).
Depending on the operating system and the system capabilities, a layer manager is used to manage the layers. There are 4 layer managers:
- D3D10 – Windows 7/Vista
- D3D9 – XP
- OpenGL – OS X
- Basic – Linux and fallback
This is not quite accurate because there is blacklist for various drivers, if a card/driver are blocklisted the basic layer manager will be used. The layer manager then implements each of the 5 main layer types on top of the 3D rendering technology (except for Basic which is cairo/thebes only) using hardware acceleration where possible. Once the layers are all rendered, the layer manager composites the results using properties on the layer such as clipping and opacity.
Hardware acceleration is becoming increasing important both to support technologies like WebGL but also for general performance. Firefox 4 was a big step forward on hardware acceleration, but project Azure will drive this even farther forward.
The Gfx team goals are laid out for Q2 (basically for FF 6 and 7) –
- Fennec layers acceleration – hardware accelerated compositing for Fennec using the OpenGL ES layer manager which is part of the OpenGL layer manager but too buggy to turn on but default currently
- Electrolysis accelerated layers – right now display and rendering happen in the same process, with Electrolysis this is not the case, so in order not to do costly readbacks from the GPU and send the texture over IPC to be sent back to the GPU in the display process, the textures need to be shared between processes where possible
- NPAPI async drawing extension – accelerated windowless plugin support on Windows
- Azure – D2D accelerated 2D canvas implementation, first step in rolling out Azure
- Mac Plugin Async Drawing – Just what it says, end sync plugin drawing on OS X
A11y is of course responsible for accessibility (on all platforms). This team was quite small until recently, but is expanding, in particular to drive web accessibility on mobile devices which is in a poor state no matter what browser and OS you are on (well, except for iOS which has recently become good).
The accessibility team is about more than just hacking too. There is engagement with other open source teams such as NVDA and GNOME, as well as initiatives such as Women of GNOME and the GNOME A11y hackfest. There is also a grant program for web related accessibility projects.
The accessibility goals are laid out for Q2:
- Begin electrolysis a11y impl – solving issues about introspecting content when assistive technologies are operating on the UI process
- Work with product management to complete mobile functional accessibility requirements and priorities – as above, need to drive a mobile a11y story
- Make all implemented HTML5 inputs accessible – new HTML spec implementation bits should always be accessible
- Finish work for accessible text interfaces to include only cached text usage – performance improvement
- Remove 75% of existing XPCOMery from the accessibility module – part of a general deCOMtamination effort
I’m also working with Ehsan. He is driving a great effort called “Orange Crush” to reduce intermittent oranges. An orange is test failure, there are a lot of these that happen from time to time only. Test failures are not good of course, but the biggest issue is it wastes time as people have to check that the oranges were intermittent after their changes land and “star” them (indicate they are acceptable) – and it takes a few hours before the tests are complete so you have to stick around when you land something. As a group intermittent oranges also happen frequently enough that you get a few every landing, which prevents doing nice things like automated landing from the test build server (the “try server”) to the main build server on successful test build run.
Mozilla is transitioning from a ship-it-when-its-done model to a continual release train model that will ship every 12 weeks with an option to ship every 6 weeks. This involves a lot of re-working of processes, tools, engineering habits, marketing and everything else that goes along in a release. Biggest of all is of course the mental shift to acknowledge that things really can wait 6 more weeks (instead of 12+ months like in FF4!). Overall this process should help to deliver features to users and web developers sooner and drive the open web more quickly.
Lots else to do like recruiting, 1:1s, goal setting, meetings, but a great environment to do it in.