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

beziers

[siokaos]

it's amazing that a mathemetician (two actually, decasteljau and bezier) came up with bezier curves to assist designing automobiles. their power is so incredible, like in this instance, they are still very common today.

the decasteljau algorithm for determining what points on a bezier curve are is quite simple. the bezier curve takes four input XY pairs (p0,1,2,and 3), which is why they're called cubic beziers, as opposed to the similar three pointed quadratic spline (like the directional arrows on some atlases). anyways, getting back to the algorithm:

;check distance between p0 and p3
;if distance>threshold, print values

;Compute p01. (p0+p1)/2

;Compute p12. (p1+p2)/2

;Compute p23. (p2+p3/2)

;Compute P012 (p01+p12)/2

;Compute P123 (p12+p23)/2

;Compute P0123. (P012+P123)/2

;call DeCasteljau (p0,p01,p012,p0123)

;call DeCasteljau (p0123,p123,p23,p3)
--
so basically, one generates two pairs (left and right) of points, and a recursive call is made with each.
.
the implications of such a simple yet elegant system in 3d beziers is amazing. this site has many resources : http://www.daimi.au.dk/~mbl/cgcourse/wiki/curves_a nd_surfaces.html

you may also want to check out
http://www-unix.oit.umass.edu/~verts/software /software.html#BEZIER

"bezeier madness", a beautiful bezier design program that 0wns windows paint.

GhostScript?

[phr2]

I know that at least part of the design goal of GhostScript was to be a basis for replacing NeWS or Display PostScript, though people settled on X instead. Why reinvent the wheel now though? If you want a PostScript-like X extension, why not use GhostScript?

Re:GhostScript?

[siokaos]

because ghostscript is a rendering system, not a nearly a new format. let alone the fact that it is severely lacking in the power of what's needed. I'm not even sure you could run fonts from a ghostscript spec ;)

That's what I mean, who needs a new format?

[phr2]

It seemed to me that NeWS was a good design--it added the obvious stuff to PostScript to use in a window system. It didn't take off because its implentation stunk and it wasn't free. But using Potsscript as the format seemed just fine. Any prob?

Re:Why?

[jukal]

I can answer myself now, as dmiller put it clearly in another thread:

" 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). "

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.

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.

That's why Acrobat/PDF

[jonabbey]

The PDF format is essentially PostScript with the ability to execute code removed, and a declarative syntax in its place (see http://www.rlg.org/preserv/diginews/diginews5-1.ht ml#feature2 for details).

The PDF file format is open, and many tools have been written to use it without involving Adobe.

Re:Goals and intentions?

[Ian Bicking]

So, my understanding from what you're saying...

The real relation to Postscript is that you're building all the graphical primitives into X (via the Render extension). But that's not related to Postscript the language, except that you could more easily build a Postscript interpreter that rendered to X, because you wouldn't have to write your own graphical routines.

But what your adding is really on the level of Xlib -- primitive graphic operations that very few people write to directly. Instead there are programming layers -- widget sets, things like Tk's Canvas, or DPS/DGS -- that would access that low level. And presumably when these layers are updated to user the Render extension, our apps will seemlessly support the new graphics (though of course most won't know what to do with the resolution independence they've just attained, but in time that will change).

Sounds very cool.