New Layout: Rendering

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 ones 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 and cache.
Image abstraction.
Interfaces to be implemented per-platform.

Rendering Context
Device Context
Font Metrics
Image

Platform dependent implementation of the per-platform interfaces listed above.

Implementation

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 math 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 and cache.

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 font cache to request a set of font metrics. The font cache simply holds a list 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.

font
transformation
clip rect
color
state stack

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.

output device resolution in terms of logical units
conversion functions to go from application defined units to device units
display zoom value

A device context is desgined to be shared among all of the higher level objects that intend to output to the device which the device context describes. As such, it also owns the font cache since all fonts on the same output device have the same properties.

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 like layout 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.

Dependencies

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.

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.

Roadmap

The highest priority is to get the platform specific code implemented on Unix and Macintosh. We have a Win32 implementation that, while very functional, has not yet been optimized.

Colormap support is complete in the Image abstraction code, but has not yet been fleshed out in the rest of the graphics system. 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 bascially 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.

We are currently implementing support for alpha blending and per-pixel image transformations. We have not yet determined where this code will live once it is all working. The intention is that we will be able to alpha blend images with alpha channels, and after rendering via the Rendering context, to be able to blend the output with another Rendering context, or it's output.

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 most likely be kept at the application level.

Communicator 4 and previous versions of the Navigator have had downloadable font technology so that a document can specify a URL for a typeface and have it downloaded on demand. In addition, special font rasterizers are necessary for fonts that the native platform does not know how to render. Similar functionality needs to be added to the graphics system.

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 and font cache.

It would be really great if we could support gamma correction of everything that goes through the rendering pipeline.

Known Bugs

Support for regions is non-existent.

Font metrics/cache/Font APIs need to allow applications to interate over the fonts available on the system at runtime to do font matching.

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

There is no support for masked image blits as needed by images such as "transparent" GIFs.