A PostScript-like API for the X Render Extension

Pivot writes: "Carl Worth and Keith Packard have started building a PostScript-like API for drawing using the X Render extension. There are two modules, called 'Xr' (the "rendering part") and 'Xc' (the "compositing part", which is a layer on top of Render which will eventually grow to a client-side Render emulator). The API supports only cubic Bezier splines, leaving other splines out of the library, similar to PostScript. Check out the initial announcement on the Render mailing list, and some example shots. Shurely this will remind some of NeWS, cowritten by another well known character."

Comments

rendering

[Anonymous Coward]

Carl Worth and I have started building a postscript-like API for drawing
using the Render extension (or a client-side Render emulator). Interested
parties are welcome to take a look at the current state of the API
in CVS at keithp.com (http://keithp.com has a pointer), the two modules
are called 'Xr' (the "rendering part") and 'Xc' (the "compositing part",
which is a layer on top of Render which will eventually grow a client-side
Render emulator).

We chatted with Lyle Ramshaw a couple of weeks ago and he suggested that we
implement only cubic Bezier splines and leave other kinds of splines out of
this library. Certainly that matches what Postscript does, and cubic
Bezier's have the nice property of being trivial to decompose into line
segments.

Filling figures bounded by a Bezier is quite easy; split the curve into
line segments and fill the resulting polygon.

Stroking these curves is somewhat more difficult. We knew that circular
pens were a bad idea; in Sharp mode, they generate lumpy lines while even
in AA mode they're computationally intractable to compute precisely.

For Sharp mode, the fix for the lumps is pretty easy -- use one of John
Hobby's pen polygons and you get a nice even stroke width along the spline.

What I hadn't realized before now is that polygonal pens solve the
computational problem as well -- instead of generating a new n-th order
polynomial describing the track of the edge of the figure, a polygonal pen
stitches translated pieces of the original path together to form the
boundary.

We know how to compute points along the spline, and certainly translating
them is easy enough, the only hard part is selecting which pieces of the
spline are glued together to form the final edges.

That part turned out to be confusing, but actually quite simple -- you move
counter-clockwise along the polygon when the counter-clockwise polygon edge
is clockwise from the spline and clockwise along the polygon when the
clockwise polygon edge is clockwise from the spline.

Another realization is that Hobby's pen polygons aren't interesting in the
anti-aliased case -- pen polygons are designed to generate the same number
of lit pixels on each scanline (and column) so that non-AA lines don't
appear lumpy, but in the AA case, we don't want to round the widths to the
nearest whole pixel like that. So, for AA splines, we just use a
symmetrical polygon with enough points to keep things looking smooth.

The final trick was to add the four points forming the start and end of
each edge of the stroke to the polygon. This preserves the precise width
of the face so that a cap or join can be applied smoothly.

Carl wrote a prototype of this algorithm, a sample of it's output
can be seen at http://keithp.com/~keithp/download/spline.png
The code for this is in the 'spline' CVS module at keithp.com and is
written in nickle with a C helper to do the actual drawing with Xr.

The sample uses colors to show the transition from one polygon vertex to
the next; there are 20 vertices forming a regular polygon along with the
four additional vertices from the spline ends. The colors of the polygon
progress counter clockwise through black, red, green, blue, yellow, cyan,
magenta and gray, as seen in the little sample polygon drawn at the start
of the spline.

How will it compare to Quartz..

[h0tblack]

It will be very interesting to see how the rendering and composting compares to Apple's Quartz in OS X. Quartz brought a lot of nice effects to OS X, but slowed down the responsiveness of the GUI, especially on older hardware. At the time there was no way of using GPU's to directly accelerate a Postscript-based engine. Quartz Extreme has partially got around this by sending parts of the process through OpenGL.
So how will this implementation get around the limitations of hardware acceleration and even in an 'unaccelerated' form how will it perform? Definitely one to watch methinks.

Re:I don't understand

[dmiller]

In addition to the already-mentioned resolution independance. This API would allow an X server to implement hardware acceleration of the rendering. I don't know if any cards support acceleration of spline decompisition, but just about everyone supports hardware-assisted polygon filling, which means many fewer pixels go over the wire (or SHM segment).

Now if only they would implement true multi-window tranparency and complete affine transformation support, then X would begin to catch up to OS X :)

Goals and intentions?

[Ian Bicking]

The email is pretty technical, and doesn't give any idea of what their goals are. Is this just fiddling around for the fun of it, or are they thinking about introducing a new extension for mainstream use?

If they are thinking of taking this someplace serious, it could be interesting. People probably remember that OS X uses PDF to display items, and its inspiration (NeXTSTEP) used Postscript. This gives resolution-independent display, and highly accurate WYSIWYG possibilities (since you render to the printer just like you render to the screen).

GNUStep is a clone of NeXTSTEP, and uses some sort of similar rendering. I'm not clear on their status -- for a long time they were waiting for a Display Ghostscript (DGS) extension, so they could copy NeXTSTEP faithfully. Proprietary Postscript extensions for X have been around for a long time. Ultimately, it seemed like someone didn't want to wait around, and wrote a straight Xlib backend for GNUStep, with none of the vector-graphics properties. I think that backend has stuck, since it works, and DGS isn't the primary platform at this point. But I'm not sure.

This could be an alternative to DGS, or something to build ontop of, or maybe it's just people fooling around with another alternative that wouldn't be useful. Obviously, fonts and anti-aliasing and all that jazz is really essential for a complete rendering platform -- just doing splines is a long ways from that.

(If you can't get to gnustep.org, try gnustep.net -- it's good stuff, even if development has been slow over the years. Too bad FSF/GNU didn't back GNUStep instead of creating GNOME -- I don't know what was up with that)

Re:Goals and intentions?

[keithp]

The email is pretty technical, and doesn't give any idea of what their goals are. Is this just fiddling around for the fun of it, or are they thinking about introducing a new extension for mainstream use?

The Render extension is designed to replace the core X rendering model for general purpose applications. Its most visible effect today is the presence of anti-aliased text in Qt and Gtk+ 2.0 applications. However, the extension is more than just AA text; it provides a complete alternative to all of the existing rendering code using colors instead of pixel values and image compositing operators instead of boolean raster ops. It's a standard part of XFree86 today and future XFree86 releases will see the remaining parts of the extension fleshed out.

Render is designed to offer the minimal extension necessary to take advantage of modern hardware acceleration. For geometric objects, the work of breaking it into primitive shapes is done on the client side of the wire; the only thing the server does is draw trapezoids (or triangles). Render is based on image compositing so it provides translucent images as well as anti-aliased objects.

Once the extension had progressed to a point where anti-aliased text was possible, I got side tracked for a year dealing with the repercussions of client-side font support. I've recently drafted Carl to help get the graphics pieces finished. He and I implemented the fundamental geometric primitive (the trapezoid) a few months ago and now we're starting to build more complex shapes based on that. As those pieces are all done in the client, we're building the Xr and Xc libraries to provide them.

Xr and Xc will likely become a part of XFree86 once they're a bit further along in development. Carl has plans to port Qt to Xr to replace the graphics operations in that toolkit, we'll see if we can't get TrollTech to pick up those changes much as they picked up the Xft changes last year. Gtk+ already has a relatively sophisticated rendering engine; I'm not sure what part Xr/Xc have to play in that environment.

Re:Is this a security hole?

[rjw57]

This is a common misconception. With this you don't literally throw PostScript at the X-server. Instead this library presents a drawing and compositing API with similar semantics to PostScript (i.e. it is a stack-based protocol with elementary drawing commands such as 'MoveTo' and 'DrawTo'). All commands are issued via function calls however not by parsing PostScript (which would introduce a) a huge overhead and b) security questions as you said).

True Display Postscript can be thought of as a rich-text version of the X11 protocol, there is little protocol-based computation which can be initiated on the server by the client, instead it simply encapsulates a set of vector and bitmap srawing commands within a consistant protocol.

I hope this have a better fate

[Per Abrahamsen]

There have been several attempts based on GhostScript to produce a real postscript API for X11.