You've reached the Gfx team! This page aims to give useful information to get started as a contributor in the Gfx team.
It is hard to keep up to date good documentation about our current projects, because they evolve quickly, and because we use Bugzilla rather to keep track of the past, present and future work. As a result, it is good to know that we are working on many more things than the few items that we try to keep up to date on this page, and that there are many possibilities for contributions that you can find by asking us on the #gfx channel on irc (irc.mozilla.org).
Bugs ahoy! can also be useful to find bugs to contribute to. Asking questions on irc will definitely help in any case.
What we are doing
Gfx stands for Graphics. This is the part of the browser engine (Gecko) that concerns itself with the final stages of the rendering of web pages, when we actually draw the contents of the page: text, images, canvas, video... Whenever possible, we use the GPU, via OpenGL or DirectX, to accelerate the drawing.
The Meet the Gfx team page presents us and explains who's working on what.
To get started, you need to do these few things, in any order:
- Make your own build of Firefox, from the source code of the development version (mozilla-central). This page explains how to do that.
- Find a mentored bug: Find a task to work on. Use this tool to find a mentored bug to work on. See below the list of current projects.
- Register an account on Bugzilla.
- IRC channel: #gfx on Mozilla IRC (irc.mozilla.org). The Meet the Gfx team page helps making sense of IRC nicknames.
- Weekly conference calls: we have bi-weekly team meetings taking place over the phone/videoconference, on Mondays 2:30pm/5:30pm Pacific time. Everyone is welcome to attend them. Dial-in details, agendas and minutes are given on each meeting's page. If you want to talk about something, please add it to the agenda.
- Mentors: Once you've found a mentored bug that you would like to work on, adding a comment on that bug is a good way to get in contact with the mentor.
- Development discussion: mostly happens on Bugzilla.
- Mailing list: The mailing list to use for serious discussion that doesn't fit on Bugzilla, is dev-platform.
- Gfx Team: Don't miss the Meet the Gfx team page!
Here's a quick overview of the tools we're using:
- Bugzilla is where most development discussion takes place. Here's some Bugzilla documentation.
- Mercurial is the SCM (source code management) tool we're using for Mozilla source code.
- Mercurial Queues is not mandatory, but is a very useful tool to work with patches.
- Compilers: we currently use Visual Studio on Windows, and GCC on other platforms. We have a plan to start building with Clang/LLVM wherever we can, starting on Mac.
- Patch review: Once you have made a patch for a bug, attach it to the bug and request review for it. It's just a matter of setting 'review?' on it and selecting an appropriate reviewer.
Here are the projects on which we're currently focusing. Help with these is welcome!
Off Main Thread Compositing
Compositing is the process of taking various sections of the page broken into layers and drawing them as a single image to the screen. This process moves this work into separate thread. This will let the browser continue to draw pieces of that page that don't require the main loop such video, plugins, some CSS animations and perhaps an experimental async WebGL/Canvas mode.
- gfx/layers is where most of the source code is.
- gfx/layers/ipc is where thread communicate code is.
- gfx/layers/opengl is where the opengl backend is (Mac, Linux, Android).
- gfx/layers/d3d9 is where the d3d9 backend is (WinXP mostly).
- gfx/layers/d3d10 is where the d3d10 backend is (Win7 mostly).
WebGL is a DOM API exposing OpenGL ES 2.0 functionality to web pages, allowing for fast 3D graphics.
Work is ongoing on conformance with the WebGL specification, and on performance.
- content/canvas/src is where most of the source code is.
- dom/interfaces/canvas/nsIDOMWebGLRenderingContext.idl is the IDL for the WebGL context.
- content/canvas/test/webgl is our copy of the conformance tests. There is also content/canvas/test/crossorigin.
- gfx/angle is our copy of the ANGLE library, providing the shader translator on all platforms and the OpenGL-on-Direct3D implementation on Windows.
OpenGL-accelerated Layers on desktop Linux
There is quite a bit of work to do here! The tracking bug is bug 594876. With the arrival of Wayland, one of the big improvements we need to bring to our Linux-specific code is to progressively remove all the dependencies to X, and migrate from GLX to EGL for OpenGL contexts (we already use EGL on Android).
Color management improvements
Other areas of the code base
Here are some other areas of the code base that are useful to know about, but that aren't the main projects we're working on at the moment.
We blacklist bad/old graphics drivers to steer clear of driver bugs. The implement this in an interface, GfxInfo, that is accessible to privileged pages such as about:support.
See the tracking bug for blacklisting improvements.
- widget/src/xpwidgets has the cross-platform code, see GfxInfoBase.* and GfxDriverInfo.* in this directory.
- widget/public/nsIGfxInfo.idl is the IDL.
- widget/src/windows/GfxInfo.cpp is the Windows-specific code.
- widget/src/cocoa/GfxInfo.mm is the Mac-specific code.
- widget/src/xpwidgets/GfxInfoX11.cpp is the X11-specific code, using data generated by the separate "glxtest" process implemented in toolkit/xre/glxtest.cpp.