Gfx glue layer removal

From MozillaWiki
Jump to: navigation, search


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


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
    • 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
  • 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/?)