Xr: Cross-device Rendering for Vector Graphics Carl Worth USC, Information Sciences Institute [email protected] Keith Packard Cambridge Research Laboratory, HP Labs, HP [email protected] Abstract from labels and shading on buttons to the cen- tral image manipulation in a drawing or paint- ing program. Xr targets displays, printers and Xr provides a vector-based rendering API with local image buffers with a uniform rendering output support for the X Window System and model so that applications can use the same local image buffers. PostScript and PDF file API to present information regardless of the output is planned. Xr is designed to produce media. identical output on all output media while tak- ing advantage of display hardware acceleration The Xr library provides a device-independent through the X Render Extension. API, and can currently drive X Window System[10] applications as well as manipulate Xr provides a stateful user-level API with sup- images in the application address space. It can port for the PDF 1.4 imaging model. Xr pro- take advantage of the X Render Extension[7] vides operations including stroking and filling where available but does not require it. The Bézier cubic splines, transforming and com- intent is to add support for Xr to produce positing translucent images, and antialiased PostScript[1] and PDF 1.4[5] output. text rendering. The PostScript drawing model has been adapted for use within C applications. Moving from the primitive original graphics Extensions needed to support much of the PDF system available in the X Window System to 1.4 imaging operations have been included. a complete device-independent rendering envi- This integration of the familiar PostScript op- ronment should serve to drive future applica- erational model within the native application tion development in exciting directions. language environment provides a simple and powerful new tool for graphics application de- 1.1 Vector Graphics velopment. On modern display hardware, an application’s 1 Introduction desire to present information using abstract ge- ometric objects must be translated to physical pixels at some point in the process. The later The design of the Xr library is motivated by the this transition occurs in the rendering process desire to provide a high-quality rendering in- the fewer pixelization artifacts will appear as terface for all areas of application presentation, a result of additional transformation operations Linux Symposium 481 on pixel-based data. However, when the images are scaled up, the differences between raster and vector artwork Existing application artwork is often generated become apparent. Figure 2 shows a portion of in pixel format because the rendering opera- the original raster image scaled by a factor of 4 tions available to the application at runtime are with the GIMP [6]. Artifacts from the scaling a mere shadow of those provided in a typical are apparent, primarily in the jaggies around image manipulation program. Providing suffi- the contour of the image. The GIMP did apply cient rendering functionality within the appli- an interpolating filter to reduce these artifacts cation environment allows artwork to be pro- but this comes at the cost of blurring the im- vided in vector form which presents high qual- age. Compare this to Figure 3 where Xr has ity results at a wide range of sizes. been used to draw the vector artwork at 4 times the original scale. Since the vector artwork is resolution independent, the artifacts of jaggies and blurring are not present in this image. 1.2 Vector Rendering Model The two-dimensional graphics world is fortu- Figure 1: Raster and vector images at original nate to have one dominant rendering model. size (artwork courtesy of Larry Ewing and Si- With the introduction of desktop publishing mon Budig) and the PostScript printer, application devel- opers converged on that model. Recent exten- sions to that model have been incorporated in Figures 1-3 illustrate the benefits of vector art- PDF 1.4, but the basic architecture remains the work. The penguin on the left of Figure 1 is same. PostScript provides a simple painters the familiar image as originally drawn by Larry model; each rendering operation places new Ewing[3]. The penguin on the right is an Xr paint on top of the contents of the surface. PDF rendering of vector-based artwork by Simon 1.4 extends this model to include Porter/Duff Budig[2] intended to match Ewing’s artwork as image compositing [9] and other image ma- closely as possible. At the original scale of the nipulation operations which serve to bring the raster artwork, the two images are quite com- basic PostScript rendering model in line with parable. modern application demands. Figure 2: Raster image scaled 400% Figure 3: Vector image scaled 400% Linux Symposium 482 PostScript and PDF draw geometric shapes by by the graphics state object in the Xr interface. constructing arbitrary paths of lines and cubic Bézier splines. The coordinates used for the construction can be transformed with an affine 2 API and Examples matrix. This provides a powerful compositing technique as the transformation may be set be- This section provides a tour of the application fore a complex object is drawn to position and programming interface (API) provided by Xr. scale it appropriately. Text is treated as pre- Major features of the API are demonstrated in built path sections which couples it tightly and illustrations, and the source code for each illus- cleanly with the rest of the model. tration is provided in Appendix A. 1.3 Xr Programming Interface 2.1 Xr Initialization #include <Xr.h> While the goal of the Xr library is to provide #define WIDTH 600 a PDF 1.4 imaging model, PDF doesn’t pro- #define HEIGHT 600 vide any programming language interface. Xr #define STRIDE (WIDTH * 4) borrows its imperative immediate mode model char image[STRIDE*HEIGHT]; from PostScript operators. However, instead of int proposing a complete new programming lan- main (void) guage to encapsulate these operators, Xr uses C { XrState *xrs; functions for the operations and expects the de- veloper to use C instead of PostScript to imple- xrs = XrCreate (); ment the application part of the rendering sys- XrSetTargetImage (xrs, image, tem. This dramatically reduces the number of XrFormatARGB32, WIDTH, HEIGHT, STRIDE); operations needed by the library as only those directly involved in graphics need be provided. /* draw things using xrs ... */ The large number of PostScript operators that XrDestroy (xrs); support a complete language are more than ad- /* do something useful with image equately replaced by the C programming lan- (eg. write to a file) */ guage. return 0; } PostScript encapsulates rendering state in a global opaque object and provides simple op- erators to change various aspects of that state, Figure 4: Minimal program using Xr from color to line width and dash patterns. Be- cause global objects can cause various prob- Figure 4 shows a minimal program using lems in C library interfaces, the graphics state Xr. This program does not actually do useful in Xr is held in a structure that is passed to each work—it never draws anything, but it demon- of the library functions. strates the initialization and cleanup proce- dures required for using Xr. The translation from PostScript operators to the Xr interface is straightforward. For ex- After including the Xr header file, the first Xr ample, the lineto operator translates to the Xr- function a program must call is XrCreate. This LineTo function. The coordinates of the line function returns a pointer to an XrState object, endpoint needed by the operator are preceded which is used by Xr to store its data. The Linux Symposium 483 XrState pointer is passed as the first argument terpretation for user units and having the ability to almost all other Xr functions. to draw elements on exact device pixel bound- aries. Ideally, device pixels would be so small Before any drawing functions may be called, that the user could ignore pixel boundaries, but Xr must be provided with a target surface to with current display pixel sizes of about 100 receive the resulting graphics. The backend of DPI, the pixel boundaries are still significant. Xr has support for multiple types of graphics targets. Currently, Xr has support for render- The CTM can be modified by the user to po- ing to in-memory images as well as to any X sition, scale, or rotate subsequent objects to be Window System “drawable”, (eg. a window or drawn. These operations are performed by the a pixmap). functions XrTranslate, XrScale, and XrRotate. Additionally, XrConcatMatrix will compose a The program calls XrSetTargetImage to direct given matrix into the current CTM and XrSet- graphics to an array of bytes arranged as 4- Matrix will directly set the CTM to a given byte ARGB pixels. A similar call, XrSetTar- matrix. The XrDefaultMatrix function can be getDrawable, is available to direct graphics to used to restore the CTM to its original state. an X drawable. When the program is done using Xr, it signi- fies this by calling XrDestroy. During XrDe- stroy, all data is released from the XrState ob- ject. It is then invalid for the program to use the value of the XrState pointer until a new ob- ject is created by calling XrCreate. The results of any graphics operations are still available on the target surface, and the program can access that surface as appropriate, (eg. write the im- age to a file, display the graphics on the screen, etc.). Figure 5: Hering illusion (originally discov- ered by Ewald Hering in 1861)[11]. The radial 2.2 Transformations lines were positioned with XrTranslate and Xr- Rotate All coordinates passed from user code to Xr are in a coordinate system known as “user space”.