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

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 :)

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.

Re:So what? Still no alpha channel?

[rjw57]

Would you really try to run a fully-alpha blended X-server on hardware that couldn't cope? No. In a similar manner you don't use fade-in transparent menus on 486s. No-one would be forced to use it (remember this is X so the programs would still run on older machines, they just wouldn't use the translucency/genie extensions).

it doesn't seem to be Display Postscript

[g4dget]

As far as I can tell from the little information that there is, what they are doing is to provide drawing primitives similar to what you get in PostScript (or Java2D, for that matter) on top of XRender, using a C-based API. They don't seem to be reimplementing Display Postscript.

That's good, as far as I'm concerned. The raw XRender interface is a bit primitive. Having a C-based API with PostScript-like drawing primitives will be really neat. That will make it much easier to get Macintosh-like screen-graphics without the mess and overhead associated with Display Postscript or Display PDF.

Re:10 years lost

[jg]

Actually, there is a fundamental difference between NeWS and what is being done in Render (and Carl and Keith's latest work).

NeWS implemented postscript in a display server; Render is only implementing the imaging primitives in the X server (in this case, AA, alphablended trapezoids), leaving anything like Postscript (or pick your favorite other graphics library) to be implemented as a client side library.

If you think Postscript is a good extension language (which NeWS was based on), you need your head examined. And machines of that era could not rely solely on a Postscript imaging model (insufficient display bandwidth available for imaging applications). What is feasible today on 1000 mip machines for applications is quite different than the 1 mip machines of that era.

Now if you want an extension language in the X server, try something like Java: note that James Gosling saw the errors of his ways with that language.... It would make infinitely more sense than NeWS ever did.

And yes, lots of time was lost: the UNIX vendors fought with each other for years rather than helping X move on. See my Usenix invited talk.

http://www.usenix.org/events/usenix2000/invitedt al ks/gettys_html/img0.htm

If you want to have something "better", either help the current efforts, or go write your own window system. Grousing about the current state of things when you aren't doing either isn't acceptable. Note that we have been learning from much research in the intervening time: Plan 9's window system is the basis for the render work; it has blazed the way for a much better imaging model with great simplicity and power.

But I never believed NeWS was the answer (then again, I'm biased).