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.

Get started

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.

Contact

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

Tools

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.
• Languages: Gecko source code is C++, the build-system is GNU Makefiles, unit tests are typically JavaScript/HTML.
• 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.

Current projects

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.

If you're interested in contributing please contact Benoit Girard or Nicolas Silva.

Files:

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

Content acceleration

WebGL

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.

Contacts: Benoit Jacob and Jeff Gilbert.

Files:

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

Driver Blacklisting

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.

Contacts: Joe Drew, Benoit Jacob, Jeff Muizelaar

Files:

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