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."
Resolution independence using a well-known vector specification.
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.
a nd_surfaces.html
e /software.html#BEZIER
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_
you may also want to check out
http://www-unix.oit.umass.edu/~verts/softwar
"bezeier madness", a beautiful bezier design program that 0wns windows paint.
http://siokaos.org/
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?
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?
" 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). "
There have been several attempts based on GhostScript to produce a real postscript API for X11.
An OpenGL X-server would support any cards which have an accelerated OpenGL driver available (including a GeForce).
Myself I have an ATI Radeon and a nVidia GeForce4 and both manage to work with DirectFB (admiterdly the nVidia needs a patch but that is a packaging issue).
Rich
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.
It works fine and is used by KDE 3.
Rich.
Yeah, it kicks ass.
What does it bring to the table over C
It's OO.
or C++
It doesn't make your brain melt. And it takes an hour to learn. And it's *real* OO. With messaging (in addition to methods, which are different) and dynamic typing and binding which really opens up wide possibilities for heavy runtime action. And no multiple inheritance. Instead, you get protocols and categories. It's kind of like Java in many ways, except that it isn't dog-slow (the runtimes have become pretty optimized over the years and there's none of that byte-code crap). Oh, and the other reason it's so fun is because of the damn fine OPENSTEP API (A.K.A. Rhapsody and Cocoa).
Using Objective C and OPENSTEP is like having sex--it's just that pleasurable to work with.
I've been developing in ObjC for nearly 6 years now. The biggest advantages of ObjC is it's simplicity, and that fact that it is really dynamic.
Some of the features that I like:
Categories: This allows you to add a method to a pre-existing class without having to have source to it. For instance, if you think the NSString class should have a urlEncodedString method, just add it. Now all NSStrings will respond to this method!
PoseAs: Even cooler. This allows a subclass to actually "pose as" it's parent. Normally a dangerous technique if you aren't careful, but it's an excellent way of tracing object interactions go or fixing library bugs.
However, I still think that the coolest part (inherited from Smalltalk) is the dynamic dispatch architecture. For instance, you can implement a method named 'forwardInvocation:' That way, if any unknown message gets sent to your instance, it will first get sent to the forwardInvocation: method allowing you a 2nd chance at processing it. This is cool because you can redirect the invocation to another object and become a transparent proxy. This makes distributed object systems EXTREMELY easy to work with.
XRender is usually enabled by default in recent builds of a XFree86 (4.2.x would be a good place to start). You can tell relatively easily if you have XRender and anti-aliased fonts by doing something like:
... I believe some patches/hacks were out there, but officially, you'll need GTK2 to get AA fonts. Qt does support AA fonts via the XRender extension - if you have that xterm thing working alright, you should be able to load the KDE control panel and in the Fonts section turn on AA to get AA fonts in all Qt/KDE apps.
... this used to be pretty difficult (a few months ago), but a lot has progressed on this front. I'd recommend some Google searches and some searches in bugzilla.mozilla.org for AA fonts. KeithP helped a whole lot in getting Moz going with AA fonts using Xrender/Xft - I believe this is what he's referring to when he stated previously that he got sidetracked for a year doing client-side font things, amongst other things, too, I'm sure.
$ xterm -fa Courier -fs 14
This should launch xterm with AA fonts (Courier at size 14). If your xterm doesn't understand the switches, then your version of XFree86 isn't recent enough.
GTK 1.2 doesn't support AA fonts, far as I know
The information on these things is out there if you search the mailing lists. By now, someone may even have put together a simple Howto.
Btw - it is possible to get AA fonts in Moz as well
Cheers.
I hate Bezier splines with a passion because they do not make intuitive sense. It makes more sense to use Catmull-Rom Splines where the control points fall on the line. It uses a simple parametric polynomial just like the Bezier, but unfortunately it lacks the subdivided-ness.
Look into it.
-- Making computers see, hear, and think... http://www.componica.com/
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.