FutureGfxWhiteboard

From MozillaWiki
Jump to: navigation, search

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.

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. Well, actually this is a lie, some more work is required to handle transforms. Pav's on it.

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?

It's a priority to work out what our Mac architecture is going to be.

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.

Canvas switch to Thebes

Can happen anytime, should be no problem, some minor work.

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. Would it better to do this in one step?

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.

This could happen anytime and shouldn't be hard. Make it happen after FF1.5 is done.

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.

Need a story for WinCE and other embedded devices. Their own cairo backend or their own thebes implementation??

Hook up Thebes printing

PS backend is far from perfect but it's improving, so Linux OK.

Can Mac use the PDF or PS backend?

Windows is a problem. Need to work with GDI printing. Adapt existing cairo Win32 backend; we'll probably have to do that ourselves. May need to borrow PS "meta surface" implementation.

Releasing Thebes Builds

We should start shipping thebes-based alphas on a given platform once the following conditions are met:

  • T-render tinderboxes set up
  • Printing "basically works" on the platform
  • No dramatic visual regressions
  • Performance is "usable" for day to day browsing
  • Plugins work in the "regular web page" case

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

Plugin issues

  • The non-transformed case is no worse than today, we can continue to have floating child windows holding the plugin.
  • The transformed case is a problem. Ideally we'd have new plugin API for full event and rendering capture (e.g., force a well defined windowless mode, specify a zoom level, preferably with the ability to hand back RGBA directly). We should work on this soon. For legacy plugins we can use platform-specific capturing methods (e.g. XDamage/XComposite) or give up.

Disable non-Thebes Gfx Backends

Conditions that must be met before we disable and stop supporting existing Gfx backends:

  • Thebes performance within 90% of old Gfx for regular workloads
  • no major visual regressions (including printing)

Remove Existing Gfx Interfaces

  • Need to have all non-Thebes gfx backends disabled (see above criteria) and be confident we can ship Thebes

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?

  • One approach:
    • make the nsIRenderingContext that wraps a Thebes gfxContext be accessible via a gfxContext getter
    • Have a "big bang" megapatch where all nsIRenderingContexts passed around in layout turn into gfxContexts; all aRC->DoFoo() calls turn into aRC->RC()->DoFoo(); low risk of regressions
      • Actually, could be broken into smaller patches where we convert one set of function signatures at a time
      • [vlad] Yes, we can add another Paint function that takes a Thebes thing, and chain into it from the converted functions
    • run around the tree renaming aRC to aCX and converting aRC->RC()->DoFoo() to aCX->DoThebesThing(); can be done piecemeal with low individual risk of regressions

Exploiting Thebes-specific rendering

During the transition we can provide a Thebes() method on nsIRenderingContext that will return the thebes context if one is available, or null. Then people can write code like if (aRC->Thebes()) { ... do beautiful Thebes drawing ... } else { ... do ugly thing ... } without breaking anything.

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?
    • We need to sort this out between ourselves

Other Layout work that will help

  • Reflow refactoring
  • View elimination (less invalidation)
  • One-Widget

Exhortation

Exhortations from brendan about:

  • solicit ongoing design and code review from Mac folks;
  • think of plugin API extensions early and mail plugin-futures@mozilla.org (ask jst@mozilla.org to join), to get major vendors thinking too;
  • build up rookie hacker-helpers into 2nd string and 1st round draft choices;
  • budget time for planning and scheduling.
Retrieved from "https://wiki.mozilla.org/index.php?title=FutureGfxWhiteboard&oldid=43156"