FutureGfxWhiteboard

These are roughly in the order in which they should be done, although much can be done in parallel.

Rendering performance tests

Need to create Trender performance tests for tinderboxes.

Search for "slow scrolling" bugs to find a trove of rendering testcases. E.g.

• https://bugzilla.mozilla.org/show_bug.cgi?id=282750
• https://bugzilla.mozilla.org/show_bug.cgi?id=90198
• https://bugzilla.mozilla.org/show_bug.cgi?id=299569
• https://bugzilla.mozilla.org/show_bug.cgi?id=295737
• https://bugzilla.mozilla.org/show_bug.cgi?id=272190
• https://bugzilla.mozilla.org/show_bug.cgi?id=201307

Also look for fixed (or not fixed) Windows bugs about scaling and tiling translucent images for places where we've done considerable hacking to try to get maximum performance. I think currently scaled and tiled translucent images, especially very small or very large ones, are our hardest rendering performance problem, so I guess they will be in the cairo world too. (Note that CSS alone doesn't require scaling and tiling of the same image, although SVG and arbitrary zoom will, of course.)

Each test will simply require loading a page and doing N synchronous paints. To implement this we may need to add a chrome-only JS API to force a synchronous paint of the entire window.

Implement Gtk2 Native Themes With Cairo

Native theme support works well on Windows.

Fix complex clipping

Clipping in cairo is busted on windows.

Complex clip areas (areas which are not the union of a set of device-pixel-aligned rectangles) do not perform well and create fringing artifacts. We can fix this by using an intermediate surface to perform clipping, but it would be better done inside cairo. roc will do this in October and try to get the patch into upstream cairo.

Cairo Quartz/ATSUI work

Cairo needs work on the Quartz backend if we plan on using that instead of glitz. ATSUI font backend needs lots of development. This is a real risk Josh needs help:

• We don't want to depend on 10.4
• APIs we need are broken and/or undocumented before 10.4
• Need to figure out what kind of context to draw with
• Need to figure out native theming issues
• Could use Glitz as a fallback, but what about ATSUI?

Thebes font work

Need to add the new Thebes font/text APIs. TextRun glyph caching, etc. New Windows font backend should use Uniscribe and suck less than our current font code. Uniscribe not a problem since we're going to drop Win9x support for FF2. "I18N issues with Uniscribe"

Add the ability to cache Thebes textrun objects in nsTextFrames

Use system Pango on Linux. Currently can run with Pango >= 1.6.

Use ATSUI on Mac.

Make low-end systems work well

Benchmark and optimize cairo for low-end systems, especially Windows.

Drop support for Win9x/ME. Still need to run well on low-end Win2K/Linux systems.

Switch over to use Thebes by default

• Conditions for flipping this switch?

Remove existing gfx

• How do we convert current rendering to use thebes instead of nsIRenderingContext? Do we do the work on a branch (monotone branch) and merge the trunk in often and then do a big landing? Or do we work on the trunk, and #ifdef all the way? Or do we just flip the switch and dispense with the ifdefs, and start using nsIRenderingContext->Thebes() in Paint implementations?

Glitz configuration whitelist

• Implement a system for detecting hardware configurations (including OpenGL driver version and actual GPU)
• Compile a whitelist of configurations for which Glitz is reliable and performant
• Have Thebes use Glitz by default in those configurations

Units work

• Eli Friedman has created a units patch that shouldn't land until after old-Gfx has gone. This will address various DPI and scaling issues.
• What do we do about non-pixel-aligned transforms and rendering? Do we want to pixel-align in layout before rendering?

Unresolved Issues

• When do we switch Thebes on by default? Should we delay until performance is as good as today for most users?

tor: We should wait until we have good performance, as we've made this particular promise at the start of the cairo work. In particular, if we switch too soon Mac is going to suffer performance-wise.

SVG switch to Thebes

SVG currently uses the cairo context directly from Thebes and promises to leave it in good condition when it's done. We eventually want to get SVG using Thebes so that we can get rid of the renderer layer in the SVG code and get better font selection/usage. The easiest way of doing this is probably in two stages: write a svg renderer with the existing layering that uses Thebes instead of cairo, then start removing the SVG renderer layer.

Thebes will need some changes for SVG. Most of these will be minor cairo API wrapping, but we might have more extensive needs for efficient textPath implementation.