Hooking Versus Punting
The terms hooking and punting refer to driver decisions on whether it provides standard bitmap drawing operations, or relies on GDI to provide them. If the driver implements engine-managed surfaces, GDI can handle all drawing operations. A driver can, however, provide one or more of the drawing functions if its hardware can accelerate those operations. It does this by implementing, or hooking, a DrvXxx function.
A driver writer may wish to implement only a subset of the drawing operations a particular graphics DDI entry point implements. For any operations the driver does not support, it can call the appropriate GDI functions to carry them out. This is referred to as punting to GDI. There are some situations in which the operation must be implemented in the driver. For example, if the driver implements a device-managed surface, certain drawing functions must be implemented in the display driver.
Hooking
By default, when a drawing surface is an engine-managed surface, GDI handles the drawing (rendering) operation. For a driver to take advantage of hardware that offers acceleration for some or all of these drawing functions for a given surface, or to make use of special block transfer hardware, it can hook these functions. To hook calls, the driver specifies the hooks as flags of the flHook parameter of the EngAssociateSurface and EngModifySurface functions.
If the driver specifies the hook flag of a function, it must provide that function in its list of supported graphics DDI entry points. The driver can optimize the operation where there is hardware support. Such a driver might handle only certain cases on a hooked call. For example, if complicated graphics are requested on a call that is hooked, it may still be more efficient to punt the callback to GDI, allowing GDI to handle the operation.
Here is another example of a driver that chooses whether to handle a hooked call. Consider a driver that supports hardware capable of handling bit-block-transfer calls with certain ROPs. Even though this driver can carry out many operations on its own, it is otherwise just a frame buffer. Such a driver will return a handle to the bitmap surface for the frame buffer as the surface for its PDEV, but it will hook the DrvBitBlt call for itself. When GDI calls DrvBitBlt, the driver can check the ROP to see if it is one of those supported by the hardware. If not, the driver can pass the operation back to GDI with a call to the EngBitBlt function.
Drivers that support device-managed surfaces must hook out some of the drawing functions; namely DrvCopyBits, DrvTextOut, and DrvStrokePath. Although GDI simulations can handle other drawing functions, it is recommended for performance reasons that drivers of this type hook out other functions, such as the DrvBitBlt and DrvRealizeBrush functions, because simulation requires drawing from and to the surface.
Punting
Punting the callback to GDI means to put in a call to the corresponding GDI simulation. In general, for every DrvXxx graphics call, there is a corresponding GDI EngXxx simulation call that takes the same arguments. As long as the driver has made the bitmap nonopaque, all parameters can be passed without change to a GDI simulation. For each call the driver punts back to GDI, the size of the driver is reduced (since the code for that functionality can be omitted). However, because the engine owns the call, the driver does not have control over the execution speed. For some complicated cases, there may be no real advantage to providing support in the driver.
Hookable GDI Graphics Output Functions
The graphics output functions that the driver can hook and the corresponding GDI simulations are listed in the following table.
| Driver Graphics Output Function | Corresponding GDI Simulation |
|---|---|
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for