Rendering
Author: Michael Plitkins
Last update: 11 October, 1998
| Overview |
| Major Components |
-
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.
| Implementation |
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:4. Image abstraction.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.
- family name
- style
- variant
- weight
- decorations
- size
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.5. Rendering Context.
- 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.
- 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.
- 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.
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.
| 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 (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.
| Roadmap |
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.