Slashdot Mirror
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."
Carl Worth and I have started building a postscript-like API for drawing
e code for this is in the 'spline' CVS module at keithp.com and is
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
Th
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.
So what is this for? Would this be used to implement a Display Postscript widget or be used directly by drawing programs or something? What's the point?
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.
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)
There is actually a great reason why X isn't dead. Extensions are that reason. The entire X rendering model was designed with no intention of surviving any more than five years, the original creators figured that by then, people would have subplanted their rendering model with a completely different one. This is a great plan, and allows for unlimited flexibilty later on, unfortunately, their original design worked well enough that noone has really bothered to change it. It has aged quite well, but needs to be replaced with a new rendering engine in order to even catch up with what is going on in the Apple world. I personally would like a complete widget set on the server side, programmers, being lazy, would use the built in widgets, and all of the sudden X would have widgets that all looked and felt the same.
Mind you, I'm a pretty big fan of OS X, but that windowmanager in there is an abomination against mankind. With no virtual desktop support (except for third party kludges), windows constantly pile up, and digging through them is a pain. Hiding the icons for minimize, maximize and close until you mouse over the title bar is also something that Apple heavily recommends against in their style guide. The cheezy effects in OS X are nice for the first week, and afterwards, you just get sick of them, fortunatly you can turn most of them off.
The thing I hate most about Quartz (even more than it's bloat) is the widgets. I don't want semi-transparent, gigantic pulsating buttons to work with, I want simple, flat and slightly tinted buttons, like Java has, give me that, and I'll be an even more happy OS X user (oh, and speed Macromedia Flash up to a reasonable speed, Apple's are supposed to be good at graphics, remember?).
This is neither.
Display Postscript is an X extension that allows a application to run postscript code which can be displayed on the screen. Expose redraw event are generated normally in X pixel coordinates while the Postscript drawing happens in device independant points per inch.
As far as I can understand (Correct me if i'm wrong) NeXT took this a step further by having the postscript graphics commands rendered by a RISC processor on the graphics board.
It looks that Xfree team is slowly extending their way out of the dead end that is the X graphics model but these problems have already been fixed by adobe display postscript on propriety unices. A technology that is as dead as a door nail according to adobe. Does anyone out there actually know of a Unix app that uses display postscript?
The free unices still don't have an equivenlant of windows GDI. which offers colour calibration, hardware acceleration of graphics primitives and most importantly a consistent way of accessing fonts that is identical when outputing to the screen or the printer (I can't find raph's weblog comment on that point on advogato.org).
Attempts have been made create a display ghostscript that is compatible with display postscript but it has stalled for a number of reasons.
IMHO the issue of display APIs for BSD/Linux is the most pressing for efficient app development.
I won't even mention the whole X versus NeWS debate. As always the inferior one won.
excuse my spelling.
could someone in a clear and simple say how does this make the life of the developers easier? Why was is this done? I quess there was something that was previously harder to do?
If the X-server was written using OpenGL textures, they could be mapped onto any mesh and hence the Genie effect would be fairly easy to implement.
Rich
Horrible trolling attempt (one of the worst I've seen), but I'll bite..
Yeah, cause they must have reverse engineered the whole PostScript spec.. it's not open or anything.. really...
Jeez, give me a break- they aren't going to get in any more trouble than someone would for implementing HTTP and HTML parsing in a product. Adobe WANTS people to use PostScript. Hence the whole open spec thing.
slashdot!=valid HTML
> From the DirectFB web-site [directfb.org], they support Matrox [...]
But only on Linux. XFree should be an OS independent project and I really disklike the attemps from the linux camp to change that with the dependency of certain features on weird linux kernel modules and the like.
Because it's a lot more than how it looks. There's an excellent API as well. Oh, and nice software development tools too.
gtk2 does, i set it up last night for gentoo;
GDK_USE_XFT = 1
also a good idea to set your xftconfig to not alias smaller than 14 or so point fonts.
check out www.gentoo.org in their forums
X looks so much better now that i did that.
Technically, a big problem with PostScript is that documents are programs. This means you can run them, but doing anything else (text extraction, editing) is tough. Even a PostScript viewer is tough; look at the GhostScript mess. Plus there's a security issue. Compare HTML, which can be usefully postprocessed in many ways.
Because PostScript was flawed as a way to do anything other than print, Adobe came out with Acrobat as a way to ship documents around. Acrobat should have been unnecessary. And then there was the eBook format.
It's annoying that we don't have a good open format for documents. This helps give Microsoft Word its dominance. Word is the cornerstone of the Microsoft monopoly. (A few days ago, someone pointed out that Word Perfect format is now open, but that happened a decade or so too late.) By now, we should understand the problem well enough that we should have a single format, or at least related formats, which are displayable, editable, and printable.
Intresting development. I've written a version of
Java that uses swing for the AWT implementation.
It runs directly on top of XLib.
See http://janux.sf.net theres even a screen shot
of Netscape running in a JInternalFrame.
The next version Jdk1.4 will embed the VM inside
the X Server. This will provide the full Java2D api
to applications. Also I plan to support SVG rendering on the desktop.
I'm working on the graphics stack issues right now
Keiths work could prove very useful. Thanks for the article.
Michael Emmel
memmel2@yahoo.com
Yes, it is interesting to note James Gosling's software history. I was a HUGE fan of NeWS at the time. (That has been one of the three elegant things in computers I ever loved passionately, others being Modula-2 and Plan 9 /Inferno.
First he and others at Sun thought PostScript is an elegant interpretable general purpose language, why not send that to GUI clients to offload arbitrary GUI widgets -- or any code -- from servers? Just add input handling and host communication to PS. You also get better vector/pixel/font/colour model than the hackish X. Vector graphics NeWS windows and fonts could be arbitrarily scaled and still use all resolution you have, i.e. on printers.
They even built a nice event model as PS widget libraries, where stacked dictionaries were an elegant inheritance mechanism.
When NeWS failed as a distributed window system (I think because Adobe destroyed that clone of PS with anti-Sun politics and their own inferior and competing DisplayPS), Gosling became soft for complaints about non-conventionality of PS stack syntax. He threw away the PS syntax and ran away from the GUI wars dropping the graphics part, but kept the idea of distributing interpretable system modules as NeWS intermediate code. NeWS did PS -> pseudocode, now his new language, first called Oak and then Java, compiled to a similar pseudocode.
So sad. NeWS lost so much possibilities and elegance when it became Java, and gained nothing excpet a new language syntax (that I hate, like I hate C++).
Note that NeWS server application were language neutral so that no matter what language you wanted to use on the server, you just wrote your widgets as PS text (or precompiled pseudocode) to the clients at initialization and later on demand by the client when first needed.
Anssi Porttikivi / app@iki.fi