Draw Device

The Draw device is the core renderer for MuPDF. Every draw device instance is constructed with a destination Pixmap (see Pixmaps Pixmaps for more details), and each graphical object passed to the device is rendered into that pixmap.


\begin{lstlisting}
/*
fz_new_draw_device: Create a device to draw on a pixmap.
...
...z_device *fz_new_draw_device(fz_context *ctx, fz_pixmap *dest);
\end{lstlisting}

Most of the time we render complete pixmaps, but a mechanism exists to allow us to render a given bbox within a pixmap:


\begin{lstlisting}
/*
fz_new_draw_device_with_bbox: Create a device to draw on ...
...h_bbox(fz_context *ctx, fz_pixmap *dest, const fz_irect *clip);
\end{lstlisting}

This can be useful for updating particular areas of a page (for instance when an annotation has been edited or moved) without redrawing the whole thing.

During the course of rendering, the draw device may create new temporary internal pixmaps to cope with transparency and grouping. This is invisible to the caller, and can safely be considered an implementation detail, but should be considered when estimating the memory use for a given rendering operation. The exact number and size of internal pixmaps required depends on the exact complexity and makeup of the graphical objects being displayed.

To limit memory use, a typical strategy is to render pages in bands; rather than creating a single pixmap the size of the page and rendering that, create pixmaps for 'slices' across the page, and render them one at a time. The memory savings are not just seen in the cost of the basic pixmap, but also serve to limit the sizes of the internal pixmaps used during rendering.

The cost for this is that the page contents do need to be run through repeatedly. This can be achieved by reinterpreting directly from the file, but that can be expensive. The next device provides a route to help with this.



Subsections