Important Notice

The pages on this site contain documentation for very old MS-DOS software, purely for historical purposes. If you're looking for up-to-date documentation, particularly for programming, you should not rely on the information found here, as it will be woefully out of date.

                                                     ◄Up► ◄Next► ◄Previous►
────────────────────────────────────────────────────────────────────────────
 
Physical objects define the attributes (such as color, width, and style) of
lines, patterns, and characters drawn by a display driver. Physical objects
correspond to the logical pens, brushes, and fonts that Windows applications
create but contain device-dependent information that the display driver
needs to generate output. A display driver creates physical objects when GDI
calls the RealizeObject function. The driver uses physical objects when GDI
calls output functions such as Output, BitBlt, and ExtTextOut.
 
The dpNumPens, dpNumBrushes, and dpNumFonts members in the GDIINFO structure
specify the number of pens, brushes, and fonts a display driver supports. A
display driver must supply information about these objects whenever GDI
requests it. GDI calls the EnumObj function to request information about
pens and brushes; it calls the EnumDFonts function to request information
about device fonts. For each pen, brush, or font, the display driver calls
the callback function. GDI pass a LPEN, LBRUSH, or LFONT structure to the
callback function. These structures specify the attributes of the object.
 
Although a display driver can use display hardware to support objects, the
driver must be able to generate the same output both on the screen and in
memory bitmaps.
 
Physical Pens
 
A physical pen specifies the color, style, and width of polylines and
borders drawn by a display driver. A display driver realizes a physical pen
by filling a PPEN structure with information about the pen. The content and
format of the PPEN structure depends entirely on the display driver. In
general, the driver copies all the information the Output function need to
draw lines.
 
A display driver should support the standard GDI pen styles: Solid, dashed,
dotted, dot-dashed, dash-dot-dotted, and empty. A display driver must
support the empty style although it is not required to supply information
about it when GDI calls EnumObj. When drawing with a empty pen, the pen
itself does not contribute to the output, but the driver may still draw a
line if, for example, the raster operation combines the destination with
itself using the XOR operator (DDx) or inverts the destination (Dn).
 
A display driver that supports wide and styled lines must use the same
drawing algorithms for lines drawn on the screen and in memory bitmaps.
Because GDI efficiently synthesizes both wide and styled lines, some display
drivers do not support them.
 
Under certain conditions, GDI may pass the display driver a request to
realize a wide or styled line even though the display driver has specified
that it does not support them. In such cases, the driver should realize a
solid, one-pixel wide (or nominal) pen. GDI will use this pen to simulate
styled and wide lines.
 
Physical Brushes
 
A physical brush specifies the color and style of patterns used to fill
figures drawn by the Output function and to combine with bitmaps drawn by
the BitBlt function. A display driver realizes a physical brush by filling a
PBRUSH structure with information about the brush. The content and format of
the PBRUSH structure depends entirely on the display driver.
 
A display driver should support the standard GDI brush styles: solid,
hatched, patterned, and hollow. A display driver must support hollow brushes
although it is not required to provide information about it when GDI calls
the EnumObj function. When drawing with a hollow brush, the brush itself
does not contribute to the output, but other factors, such as a raster
operation that combines the destination with itself or inverts the
destination, can cause the driver to generate output.
 
The display driver can dither solid brushes if the specified color does not
exactly match a physical color. Otherwise, it should choose the closest
available color for the brush.
 
The display driver should support the standard hatched brush styles:
horizontal, vertical, forward diagonal, backward diagonal, cross, and
diagonal crosshatch. On raster displays, a driver typically implements these
styles as predefined, 8-by-8 bit patterns.
 
On color displays, the display driver should support both monochrome and
color bitmaps for patterned brushes. When drawing monochrome bitmaps, the
driver sets 1 bit to the current text color and 0 bits to the current
background color. The text and background colors are specified in the
DRAWMODE structure passed to these functions. A display driver is not
required to provide information about patterned brushes when GDI calls the
EnumObj function.
 
 
                                      ♦