Gfx glue layer removal
From MozillaWiki
Goal [edit]
- 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 [edit]
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 [edit]
(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 (where is the implementation?)
