Gfx glue layer removal

Goal

• Eliminate the glue layer in gfx/src/thebes
• All code calls gfx/thebes interfaces directly
  • mostly this is nsIFrame::Paint methods, but there are others
• Not possible to implement a non-cairo rendering backend anymore
  • I believe this is already not possible; several nsIFrame::Paint methods already call gfx* interfaces directly
  • Non-Thebes gfx/src/* backends should be deleted early in the process, to remove false hits from automated scans for code needing conversion
  • I am unclear on whether gfx/src/psshared is still useful
  • Code loose in gfx/src and gfx/src/shared needs to be dealt with case-by-case
• End point: should be possible to remove gfx/src altogether (perhaps gfx/thebes/src becomes gfx/src, gfx/thebes/public merged into gfx/public?)

Plan

This will be a several-stage effort. The overall tracking bug is bug 430829.

• Use Cairo CTM instead of explicit conversions to go from layout to device units. bug 430825
  • Add defensive measures against higher-level code clobbering the CTM. bug 430827

• Identify and strip source files which are currently unused or can easily be made unused
  • nsITheme.h - move to widget/
  • nsTransform2D - barely used, users probably better off with custom code
  • Non-Thebes gfx backends
    • gfx/src/photon (see bug 384057 and bug 383868).
    • gfx/src/beos (see bug 370014 and bug 379167
  • vestigial Postscript code (gfx/src/psshared) - to investigate
  • possibly others

• DeCOMtaminate where appropriate, eliminating nsI classes
• For each cluster of objects listed below under "Classes involved", refactor all code out of the non-gfx* classes, so that they are perfect wrappers or even typedefs for the gfx* classes
• Bubble use of gfx* direct interfaces upward into paint methods, layout class data members, etc. until all uses of the old interfaces are gone

Classes involved

(this section needs to be revised per mailing list discussion)

• Graphics objects: these come in clusters, either ns<thing> and gfx<thing> parallel implementations, or an nsI<thing> interface, a nsThebes<thing> shim, and (usually) a gfx<thing> real implementation. In both cases the desired end point is that there is only gfx<thing>.

nsFont, gfxFont

nsColor, gfxRGBA

nsCoord, gfxFloat

nsPoint, gfxPoint

nsRect, gfxRect

nsSize, gfxSize

nsMargin (no equivalent?)

nsTransform2D, gfxMatrix

nsFontCache, gfxFontCache

nsIFontMetrics, nsIThebesFontMetrics, nsThebesFontMetrics, nsBoundingMetrics, gfxFont::Metrics

nsIImage, nsThebesImage, gfxIImageFrame, gfxImageFrame, gfx*Surface (?)

nsIRegion, nsRegion, nsThebesRegion, nsIScriptableRegion, nsScriptableRegion

nsTextDimensions, gfxGlyphExtents (?)

nsIFontEnumerator, nsThebesFontEnumerator

• Context classes: like the graphics objects, they come in clusters, but I think we want to collapse all of these into one class, gfxContext. (If the distinction between device context and rendering context is useful - I have no hard evidence, though I suspect it isn't - we would want to keep nsRenderingContext too, but de-COM it.)

nsIDeviceContext, DeviceContextImpl, nsThebesDeviceContext

nsIRenderingContext, nsRenderingContextImpl, nsThebesRenderingContext

gfxContext

• Thebes-only graphics objects: there is no nsI-level interface to these (that I found). Probably they can be left alone.

gfxFlattenedPath, gfxFontGroup, gfxFontStyle, gfxMatrix, gfxPattern, gfxSkipChars, gfxSkipCharsBuilder, gfxSkipCharsIterator, gfxTextRun, gfxTextRunCache, gfxTextRunFactory, gfxTextRunWordCache

• Helper classes: probably do not need messing with except incidentally.

gfxContextAutoSaveRestore, nsRegionRectIterator

• Thebes internal implementation and unit tests (I think). Again, probably do not need messing with except incidentally.

gfxASurface, gfxImageSurface, gfxXlibSurface, gfxXlibNativeRenderer, other gfx*Surface and gfx*NativeRenderer classes not used under X11/gtk

gfxFontNameList, gfxFontTestItem, gfxFontTestStore, gfxPangoFont, gfxPangoFontWrapper

other gfx*Font* classes not used under X11/gtk; note that Pango has ATSUI and Uniscribe back ends, but using Pango universally, if desirable, should be a separate project

gfxPlatform, gfxSparseBitSet

• Other things defined in gfx headers, whose role I am uncertain of:

nsColorNames, nsCUPSShim, nsPSPrinterList, nsITheme (implemented in widget/src/platform/nsNativeThemePlatform.cpp; move to widget/?)