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?
Why is there still no alpha channeling? What about genie effect?
how much money would it take to get this code written?
If you use Linux, please help development of Autopac
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.
1. X is bloated and should be replaced with something new and spiffy.
2. Why can't I have transparent windows with the background updated in real time? Lazy X developers.
3. Speaking of X, KDE is better than Gnome.
4. Speaking of KDE, Gnome is better.
5. I can't compile X.
There. Can we talk about new stuff this time?
Can you hear me, Major Tom? I'm not the man they think I am at home...
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?).
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?
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
" 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). "
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.
Rich
There have been several attempts based on GhostScript to produce a real postscript API for X11.
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.
Actually, there is a fundamental difference between NeWS and what is being done in Render (and Carl and Keith's latest work).
t al ks/gettys_html/img0.htm
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/invited
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).
OSF didn't decide that X was the way to go. OSF picked a toolkit to write a standard specification for, so that people would write apps to that toolkit and expect it to work across platforms.
That the toolkit was for X was because people were using X.
NeWS was honestly ahead of its time, because it required 10x the computing power that was available at the time. I.e., it was SLOW. That, and the fact that it wasn't free (as mentioned above) were what sealed it's fate.
I used NeWS1.0 on a Sun3/160 in 1986. I still remember the pain.
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.
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