You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Author: Michael Plitkins
Last update: 11 October, 1998

    The graphics subsystem of NGLayout is ultimately responsible for displaying "bits" on output devices. This includes standard graphical primitives such as lines, rects, bitmaps, text, etc. It is not a do-all rendering system. The scope of functionality at this time is limited to what one needs in order to output HTML-like graphics. A more in-depth description follows in the sections below.

Major Components
There are basically two separate pieces to the graphics system:

  • Platform independent set of structs, classes and interface definitions. These can be broken down as follows:

    • Geometrical primitive management (rect, point, margin, size, transformation, etc.)
    • Color definitions.
    • Font specification.
    • Image abstraction.
    • Interfaces to be implemented per-platform.

      • Rendering Context
      • Device Context
      • Font Metrics
      • Image
      • Region
      • Alpha blender

  • Platform dependent implementation of the per-platform interfaces listed above.
1. Geometrical primitives.
This is a collection of classes to represent 2D objects such as points, margins, lines, rectangles and sizes. In addition there is a transformation class that knows how to deal with scale, translation and matrix concatenation operations. Most classes support operator overloading to allow mathematical operations to be expressed succinctly.
2. Color definitions.
All colors are defined as RGBA values in the range 0-255 bit shifted to fit into a 32 bit unsigned word for efficiency. As a result, a certain amount of type safety is sacrificed. Macros are provided for packing and unpacking the various color components. There are also a set of lookup tables to go from named colors to RGBA values.
3. Font specification.
The font struct holds all of the information necessary a particular typeface. This includes:
  • family name
  • style
  • variant
  • weight
  • decorations
  • size
The font struct is used in conjunction with the device context to request a set of font metrics. The device context has a cache of the various font metrics that have been requested to date and creates new ones from fonts when a new font specification is encountered.
4. Image abstraction.
This is a set of interfaces and classes that interact with the Netscape image library to convert images from URLs to platform independent image data. To convert to actual bitmaps that can be rendered, the platform specific image class is necessary.

  • An ImageGroup allows a user to manipulate and observe a collection of image loading requests.

  • ImageRequests can be manipulated and observed individually.

  • A user of the image library can provide ImageObservers at either the group or individual request level.
5. Rendering Context.
    The rendering context is where all of the other pieces of the graphics library come together to actually display bits on an ouput device. As such, the rendering context implementation is unique to each type of output device. The rendering context, in addition to converting geometrical primitives to bits, also does state management including:

    • font
    • transformation
    • clip rect
    • color
    • state stack
    • internal state as necessary per-platform
    • string length measurement

    Since the rendering context is the focus point for manipulating bits, there are additional methods for creating offscreen drawing surfaces and managing double buffering.

6. Device Context.
    In order to interface with the underlying system's graphics and UI facilities in a stateless and lightweight XP fashion, the device context was created. The device context is essentially a set of methods for querying the system about such things as:

    • output device resolution in terms of logical units
    • conversion functions to go from application defined units to device units
    • display zoom value
    • font specification to metrics conversion
    • creation of rendering contexts suitable for the device
    • gamma correction

    A device context is desgined to be shared among all of the higher level objects that intend to output to the device described by the device context.

7. Font Metrics.
Font metrics contain all of the properties of the glyphs of a typeface. Behind the XP font metrics interface is a platform dependent implementation that may represent vector based fonts such as Adobe Type 1, True Type, bitmap fonts or anything else that the output device is capable of rendering. The font metric methods are typically used by things such as a layout system to perform text measurement.
 8. Image.
Bitmaps usually have a very platform specific representation. The Image class is an encapsulation of the underlying native platform bitmap structures. Images can be either 8 or 24 bits per pixel on the XP side of the interface (whatever is closest to the native format) and can have any representation necessary on the implementation side of the interface. In addition to holding an array of bytes or triples representing pixel information, images also have an optional alpha channel and colormap for 8 bpp images. Gamma of the image color information can be queried. Since some platforms can render bitmaps faster if the bitmap is converted to an "opaque" format that only the underlying hardware understands, there are methods for optimizing a bitmap and querying for optimized status.
9. Regions.
A region is a data structure that describes a masked area through which drawing is permitted in a rendering context. Regions can be created implicitly through various calls to the rendering context's SetClipRect() method, or explicitly by creating a region and adding or removing rects from the region.
10. Alpha blender.
In order to allow for translucency effects, there is an object called a Blender that knows how to take two bitmaps, scale one by a value between 0 and 1, scale the other by the inverse of that value and add them together.

Since the graphics system is one of the lowest level ones in NGLayout it does not rely on the rest of the codebase for much. With that said, it currently has knowledge of the Widget library so that a Rendering context can be initialized from the state information contained by a Widget (truth be told, a rendering context can also be initialized from a view, but this dependency will soon be removed).

For printed output, the application using the graphics library will be responsible for printer discovery and initialization of a device context with information relevant to the printer that it represents.


Colormap support is complete in the Image abstraction code, but has not yet been fleshed out in the rest of the graphics system on all platforms. We anticipate storing the colormap in the Device context since there is a one-to-one mapping between an output device and a device context. The default colormap will be a color cube very similar to, if not the same as, that used by Communicator 4. Applications that wish to modify the color map will essentially clone the device context and then be responsible for selecting the colormap in the device into the display when their windows get focus. This will basically mean that a Device context represents all output device parameters including color lookup and that when a different colormap is desired you are considered to be outputting to a different device. An interface representing colormap abstraction of platform native colormap structures will be necessary to achieve this.

There is a very large hole where printing is supposed to be. This entails creating a new set of rendering context, device context, font metric and image objects that know how to deal with printed output. Printer discovery is a separate issue that will be kept at the application level.

While the APIs for document zooming (scaling) are there, very little is underneath them. Some work needs to be done at the applicaition level to properly support zooming, and the rest needs to be done in the device context.

Known Bugs

We need to look at issues regarding internationalization including font encoding, performance and font metric APIs.