Gfx glue layer removal: Difference between revisions

Latest revision as of 18:33, 21 March 2010

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

@@ Line 4: / Line 4: @@
 * All code calls <tt>gfx/thebes</tt> interfaces directly
 ** mostly this is <tt>nsIFrame::Paint</tt> methods, but there are others
-* Not possible to implement a non-Cairo rendering backend anymore
+* Not possible to implement a non-cairo rendering backend anymore
 ** I believe this is already not possible; several <tt>nsIFrame::Paint</tt> methods already call <tt>gfx*</tt> interfaces directly
 ** Non-Thebes <tt>gfx/src/*</tt> backends should be deleted early in the process, to remove false hits from automated scans for code needing conversion
@@ Line 13: / Line 13: @@
 == Plan ==
-* Work out unit conversion issues (see next section)
+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
+** <tt>nsITheme.h</tt> - move to widget/
+** <tt>nsTransform2D</tt> - barely used, users probably better off with custom code
+** Non-Thebes gfx backends
+*** <tt>gfx/src/photon</tt> (see {{bug|384057}} and {{bug|383868}}).
+*** <tt>gfx/src/beos</tt> (see {{bug|370014}} and {{bug|379167}}
+** vestigial Postscript code (<tt>gfx/src/psshared</tt>) - 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-<tt>gfx*</tt> classes, so that they are perfect wrappers or even typedefs for the <tt>gfx*</tt> classes
 * Bubble use of <tt>gfx*</tt> direct interfaces upward into paint methods, layout class data members, etc. until all uses of the old interfaces are gone
-== Unit conversion ==
+== Classes involved ==
-Issues:
+(this section needs to be revised per mailing list discussion)
-* layout should still do its work in <tt>nscoord</tt> units (1/60th of a CSS pixel), per offline discussion with dbaron
-* gfx is expecting <tt>gfxFloat</tt> units (device pixels)
-* we don't want to sprinkle conversions through every paint method
-* because <tt>gfxFloat</tt> is a floating point type, changing the sequence of arithmetic operations may change what actually gets drawn (see {{bug|376180}} for an example of this)
-* <tt>nsRenderingContextThebes</tt> currently has easy access to the nscoord-to-device conversion ratio (<tt>mP2A</tt> and the <tt>FROM_TWIPS</tt>[sic] macros), whereas it's somewhat awkward to get it from a paint method (<tt>PresContext()->AppUnitsPerDevPixel()</tt> is the best way I can find, and that expands to something like four pointer dereferences under the hood).
-Possibilities:
-* keep the conversions at the layout/gfx interface:
-** define implicit conversion operators, so passing <tt>nscoord</tt> and related types to <tt>gfxContext</tt> functions makes the compiler generate conversion code in the paint method
-*** for this to work, <tt>nscoord</tt> would have to be a class type
-*** the conversion operators would need to know the conversion ratio; see above
-** change <tt>gfx{Float,Point,Size,Rect}</tt> to take <tt>nscoord</tt>-family inputs and convert internally
-*** for this to work, <tt>gfxFloat</tt> would have to be a class type
-*** also, these types would need to know the conversion ratio, which might mean they need to be told what <tt>gfxContext</tt> they're being created for
-* push the conversion down into gfx:
-** overload all <tt>gfxContext</tt> methods to take <tt>nscoord</tt> family arguments, do the conversions in the thebes layer
-*** ugly, exposes <tt>nscoord</tt> types in gfx
-** make the cairo transformation matrix do all the work (so the thebes layer continues to use its own types, but the numbers are in the same units that layout uses)
-*** facilitates replacing <tt>ns*</tt> types with <tt>gfx*</tt> types bubbling upward
-*** could be error prone if anyone else messes with the matrix
-** might not give the same rounding behavior as currently
-* other ideas?
-Overall I like "make the cairo transformation matrix do all the work"
-best, but I'm worried about its getting messed with.  Perhaps we can
-enforce a use discipline similar to PDF's - you can save and restore
-the current matrix, you can "concatenate" a transformation onto the
-existing matrix, but you can't wipe out the existing matrix and start
-over.
-== Classes involved ==
 * Graphics objects: these come in clusters, either <tt>ns&lt;thing&gt;</tt> and <tt>gfx&lt;thing&gt;</tt> parallel implementations, or an <tt>nsI&lt;thing&gt;</tt> interface, a <tt>nsThebes&lt;thing&gt;</tt> shim, and (usually) a <tt>gfx&lt;thing&gt;</tt> real implementation.  In both cases the desired end point is that there is only <tt>gfx&lt;thing&gt;</tt>.
@@ Line 116: / Line 93: @@
 * Other things defined in gfx headers, whose role I am uncertain of:
-:::: <tt>nsColorNames</tt>, <tt>nsCUPSShim</tt>, <tt>nsPSPrinterList</tt>, <tt>nsITheme</tt> (where is the implementation?)
+:::: <tt>nsColorNames</tt>, <tt>nsCUPSShim</tt>, <tt>nsPSPrinterList</tt>, <tt>nsITheme</tt> (implemented in <code>widget/src/<var>platform</var>/nsNativeTheme<var>Platform</var>.cpp</code>; move to <code>widget/</code>?)
+[[Category:Mozilla 2]]

Gfx glue layer removal: Difference between revisions

Latest revision as of 18:33, 21 March 2010

Goal

Plan

Classes involved

Navigation menu

Search