Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
X GUI

A PostScript-like API for the X Render Extension 193

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."
This discussion has been archived. No new comments can be posted.

A PostScript-like API for the X Render Extension

Comments Filter:
  • I can finally render all those beziers I have lying around in my closet...

    I'm sorry.
    • Sun did something similar in the Network Extendable Windowing System (NeWS). This was in the days of the OSF. The OSF decided that X and Motif were the way to go and left Sun out on a limb with what, IMHO, was a better system.
      • 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.
  • rendering (Score:5, Interesting)

    by Anonymous Coward on Tuesday August 13, 2002 @01:29AM (#4059852)
    Carl Worth and I have started building a postscript-like API for drawing
    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
    The code for this is in the 'spline' CVS module at keithp.com and is
    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.
  • by gralem ( 45862 )
    Isn't this a little like combining X & NeXT? I'm probably off on my technology analogy, but even though DisplayPostScript is not based on X at all, wasn't the desing philosophy the same?

    I hate to soap-box here, but it looks like the 10 things that would change the computing world may really do that. I always thought they'd be lucky if 7 of them held true.

    ---gralem
    • Re:NeXT (Score:2, Interesting)

      by Anonymous Coward
      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.
      • NeXT did not have any kind of co-processor that did anything very complicated (it may have had something doing bitblt but certainly nothing that could be considered "rendering postscript").

        In my opinion Display Postscript is seriously flawed by an absurdly difficult interface for drawing the postscript. It is designed ONLY to "preview" a document and nobody ever writes a program that uses it to draw the interactive display. NeXT was better in that, although it used the DPS interface, it used ONLY that interface, you used PostScript to create and manipulate windows and thus you did not have to learn how to interface both DPS and X (or whatever). NeXT then messed this up by insisting that people use NeXTStep, but that is another story. NeWS shows how it should be done: the interface was an absurdly simple stream interface, with simple token substitution so that common PostScript commands could be 1 byte and numbers could be sent as raw data. A NeWS program was the only one that could dump it's entire user interface to the server with a simple block copy.

        I have no idea why you are saying GDI32 is good, unless you are trying to troll here. It is exactly like X interface, in fact many parts of it are copied (there is no other explanation for the exact correspondence of the dashed line interface or the inane use of "points" to measure fonts when everything else is measured in pixels, these things were copied from X). Fonts are enormously better on GDI32 as you say. But unless you are living under a rock you would know that X uses hardware acceleration as well. And neither system does anything about color management, and neither of them should, this requires too detailed knowledge of the data being presented and is best left to the application. In fact X has a (fortunately abandoned) mess of CMS calls and I thought the LACK of these is one of GDI32's advantages, because you can assumme they do nothing.

        Because of the horrid DPS interface I don't think there is any interest in emulating it. I would like to see a stateful interface like NeWS where there is no "context" argument to the calls (you can use the same tricks as OpenGL so multithreading is supported). I have not looked at what they are considering yet so I can't comment on it, but some of the XRender extension is pretty good, though I don't like the enforced creation of per-window objects.

  • I don't understand (Score:3, Interesting)

    by KidSock ( 150684 ) on Tuesday August 13, 2002 @01:33AM (#4059862)
    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?
    • by Anonymous Coward
      Resolution independence using a well-known vector specification.
    • by dmiller ( 581 ) <djm.mindrot@org> on Tuesday August 13, 2002 @01:59AM (#4059936) Homepage

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

  • Like the Barenaked Ladies song "Its all been done".

    Someone should simply merge the SVG graphics or PDF graphics format ala Quartz into the X11 Server.
  • Anyone know how easy/hard it would be to make Qt/KDE or Gtk/GNOME use this for the display of the whole desktop in the future? Is something like that one of the reasons they are doing it?
  • Does the x render extension work now? I can only find very little documentation on it. Isn't it supposed to provide true transparency and neato anti aliased fonts (I still don't know how to get anti aliased fonts working. Does gtk 1.2 support them?)

    Anyway, Can i load up render and try these features out in the current X release or is this just the future...


    • Theres no easy way to use Xrender so no ones using it.

      Why dont you ask keith packard because I dont know, but I hope they get alpha channel working soon
    • by Jobe_br ( 27348 )
      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:

      $ 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 ... 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.

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

      Cheers.
    • My impression is that the antialiased fonts work fine (you do have to convince your software to use them but I expect the next versions of KDE and Gnome will be this way by default).

      However I have had no luck using it to draw anything other than fonts. It is supposed to draw antialiased filled trapazoids (which can then be used to draw any shape antialiased) but I have had no luck in getting them to work. I suspect there are a lot of bugs in the current implementations. This unfortunately means nobody uses them and thus nobody fixes the bugs...

  • by HanzoSan ( 251665 ) on Tuesday August 13, 2002 @01:44AM (#4059895) Homepage Journal


    Why is there still no alpha channeling? What about genie effect?

    how much money would it take to get this code written?
    • Not a great deal if you just wanted it to work. Writing a rootless X server where each window is an OpenGL texture is certainly possible (with a similar amount of work to the XDirectFB [directfb.org] rootless server for DirectFB). With the DirectFB server translucency is certainly possible (screenie [ucam.org]).

      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.


      • we know that, but we want to be able to run KDE and gnome. We NEED X for compatibility reasons.
        • I can run KDE quite hapilly on XDirectFB and the screenshot I linked to was running GNOME!

          • What video card as you using? You forget theres going to be alot more problems, alot of hardware wont work with it, alot of software wont work with it. Just because you are lucky and it works for you doesnt mean it will work for everyone else. If it does work so well why arent we all using it?
            • 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).

              • Ok when theres support for ATI and Nvidia cards and not just Matrox, then I'll pay attention.

                I'm pretty damn sure my ATI which can do alpha channel in windows can do the same in linux, also consider the fact apple uses the ATI card too, oh and the Gforce definately has the power so lets not even go there.
                • From the DirectFB web-site [directfb.org], they support Matrox G200/G400/G450/G550, ATI128, Voodoo 3, NeoMagic, Savage and CyberPro.

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

                  • > 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.
    • Everybody here please learn that this has nothing to do with "transparent windows". You could write a "transparent window" window system with NO graphics (the client program must supply the contents of a window as a 4-byte/pixel image with alpha transparency). Conversely you can draw elaborate high-level graphics with no transparency, just like a PostScript printer cannot make the paper transparent but is still useful despite this handicap.

      Although both goals are useful, please realize that they have nothing to do with each other, except that the transparency of a window will probably be determined by accumulating the transparent paint that the rendering system will use (but such transparent paint is useful even if there are no transparent windows).

      This addresses the high-level rendering end and has nothing to do with "transparent windows".

  • by h0tblack ( 575548 ) on Tuesday August 13, 2002 @01:51AM (#4059913)
    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.
    • I hope the developers keith and the other guy respond to your post.

      How exactly WILL it compare to Apples Quartz? Because thats all that really matters here. Will it compete with OSX or not?

      The hardware limitation isnt a big deal, first of all OpenGL will work just fine, second why the hell would they go through all this work if its just a software hack? IF we want a software hack we can just use enlightenment which does alot of software effects or we can use KDE and use the little transparency hack effect.
    • Actually, QE doesn't really get around it. If you look at the PowerPoint Apple put out, all QE does is accelerated compositing of windows to the desktop and accelerates stuff like the genie effect. It doesn't seem to accelerate the actual drawing of PDF paths (even though it would be trivial with current OpenGL hardware to do so).
    • Quartz brought a lot of nice effects to OS X, but slowed down the responsiveness of the GUI, especially on older hardware.

      Quartz overhead comes from several sources. First, there is PDF. X11+XRender doesn't incur that at all because it uses a C API and a binary protocol.

      Second, there is the imaging model. OSX really makes most applications other than games go through the same high-level imaging model. That's nice in certain ways, but completely unnecessary in many applications. A toolkit, for example, can often completely dispense with the possibility of anti-aliasing or geometric transformations and doesn't need to pay the overhead. X11+XRender gives programmers a choice for what kind of imaging model they want, for each particular call.

      Still, I suspect that X11+XRender will be faster than Quartz even for applications using the same imaging model and putting the same graphics on the screen. We'll just have to wait and see. Maybe Apple will eventually switch OSX over to X11+XRender :-)

  • Let's skip: (Score:4, Funny)

    by JollyTX ( 103289 ) on Tuesday August 13, 2002 @01:54AM (#4059920)

    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? ;)
  • by Ian Bicking ( 980 ) <ianb@@@colorstudy...com> on Tuesday August 13, 2002 @02:03AM (#4059948) Homepage
    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?

    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 [gnustep.org] 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 [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)

    • I think it's objective-c. Who writes apps in objective-c anymore?
      • I think it's objective-c. Who writes apps in objective-c anymore?

        NeXTstep was Objective C - not sure if GNUstep is as well. In any case, what is wrong with Objective C? In the last 8 years since I first heard of it, I've never actually learned ObjC, but I've also never heard anyone say anything bad about it. Quite the contrary: people who use it seem to love it. They say it gives you an object-oriented abstraction as a conceptually lightweight extension to C, as opposed to the syntax city which is C++.

        Seriously - would anyone who does know Objective C care to comment? Is it a decent language? What does it bring to the table over C or C++?

        • by Art Tatum ( 6890 )
          Seriously - would anyone who does know Objective C care to comment? Is it a decent language?

          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.

    • by keithp ( 139560 ) on Tuesday August 13, 2002 @03:53AM (#4060185) Homepage
      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.

      • Are there any XFree86 drivers that actually accellerates XRender operations?
      • 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.

        How far off are we to getting these basic operations hardware accellerated? I.e. what needs to be done still? For real translucancy I read that we need another X extension. Isn't it possible to draw each toplevel X window in an offscreen buffer (a la Quartz Extreme) and then use XRENDER to composite all these windows to the final root window?

        Thanks...
        -adnans
      • 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.

    • I have never understood this obsession people have with NextStep (WindowMaker, GNUStep, Afterstep etc). Sure, it looked nice at the time - but it is time to MOVE ON people!
      • I have never understood this obsession people have with NextStep (WindowMaker, GNUStep, Afterstep etc).

        It's just another side of the coin where all non-NeXT-esque window managers and GUI toolkits look like either (a) Motif, (b) Windows 95 or (c) TWM/Athena. (Oh, and Open Look, but talk about ugly.)

        Then there are the polymorphic scripted window managers and themeable / skinnable GUI components which give you a choice between NeXT, Motif, Windows 95 and TWM/Athena.

        (:

      • I could say the same thing about MacOS (X), Windows, Linux, BSD ;)

        NeXTStep was a seriously spiffy and technically advanced OS that never really made it, but that spiffiness appeals to geeks. I admire NeXTStep, but I understand that a certain Steve Jobs killed it off (MacOS X is based on it though, let's see if Mr. Jobs kills that one as well).

        But porting APIs to *nix won't really make it into NeXTStep...
        • Um, you are aware, of course, that Steve Jobs, as the founder and CEO of NeXT, is responsible for NeXTStep existing in the first place?
        • Your history is a little off. OS X is NeXTSTEP (reborn). And porting APIs to a *nix will make it a NeXTSTEP clone, because NeXTSTEP, just like OS X, was built off a BSD core. Obviously you don't get the trademark along with it, so it's just a clone :)

          There's distribution-level issues (filesystem layout and so on), but you can fake that if you need to.

      • Because it's a lot more than how it looks. There's an excellent API [apple.com] as well. Oh, and nice software development tools [apple.com] too.
    • The xlib based backend is still the primary backend, but there are alternatives: there's an experimental GhostScript-based backend, and there's back-art, which uses libart and freetype to render stuff. It's fully usable once compiled and configured (which is still tricky, but this is alpha stuff). Screenshots and source at http://w1.423.telia.com/~u42308495/alex/backart/ [telia.com] . (Disclaimer: I wrote and maintain back-art, and I use it exclusively.)
  • Does this (and display postscript in the X server) present a security risk? As I understand it, X under Linux runs SUID, enabling stuff like DRI to access the hardware directly. Would it be possible for someone to write malicious code that ran in this environment as root?
    • by rjw57 ( 532004 ) <richwareham@user ... t ['efo' in gap]> on Tuesday August 13, 2002 @02:36AM (#4060035) Homepage Journal
      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.

      • If you put loops into the language, does this present a nice denial of service approach?

        Would there be a limit on how much code you could execute at once?

        It sounds like it could be potentially flawed otherwise, and yes, I know there are a number of flaws in X anyway (in terms of nasty things you can do) if you have a client connected to a server
        • If you put loops into the language, does this present a nice denial of service approach?

          I doubt you could force infinite loops in the drawing engine from any application. Clients are after all scheduled on the X server, much like regular processes are scheduled on the CPU. Of course if your client has a higher priority than all the other drawing clients you could effectively lock them out, but that implies having enough rights to gain lower niceness levels anyways.

          What I'd really like to know if this new drawing engine will allow us to do similar thing like Quartz Extreme. I would love to use the power that's locked into my Geforce4 for regular 2D (read: xterm) needs :-) My stomach always turns when I see l33t Linux pseudo transparant xterm's and KDE/GNOME widgets in screenshots...

          -adnans
  • beziers (Score:4, Informative)

    by siokaos ( 107110 ) on Tuesday August 13, 2002 @02:20AM (#4059991) Homepage
    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? (Score:3, Informative)

    by phr2 ( 545169 ) on Tuesday August 13, 2002 @02:23AM (#4059997)
    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? (Score:3, Informative)

      by siokaos ( 107110 )
      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 ;)
      • 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?
        • Actually the first implementation was pretty good. The second version (that most people saw) was seriously broken by an attempt to make it X11 compatable in a parallel way (rather than emulate X11 atop it like was first attempted).

          The real reason NeWS died was that the source code was not open. For $100 you could buy a tape from the X consortium and that gave you the right to produce your own version of an X server (note it was not free-as-in-beer, but "open", RMS would disagree about open because there were limits on what you could do with the code, but most people would call it "open".) I'm not sure what Sun wanted, but only SGI was able to afford it.

        • If you like that style of window system, it's still around and very popular: it's called Java. Same stack based architecture, same imaging model, only this time they got the threading and type checking right. And it's actually powerful enough to do real work on the display side.
    • This doesn't seem to be Postscript-for-X11, but a Postscript-like API callable from C. Think "Java2D for C".
  • Why? (Score:2, Interesting)

    by jukal ( 523582 )
    As I, (and I believe 96 percent of /. users, atleast those date to say it), dont know even closely enough about this field to understand the reasoning for this development work,

    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?

    • Re:Why? (Score:3, Informative)

      by jukal ( 523582 )
      I can answer myself now, as dmiller [slashdot.org] 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). "

    • by cduffy ( 652 )
      It's not just a developer thing -- by pushing rendering client-side, this has the potential to make remote displays much faster for programs doing much more complicated graphics than can be represented with XDrawLines and such (as well as resulting in better display output and just generally being Good Stuff).
  • by Per Abrahamsen ( 1397 ) on Tuesday August 13, 2002 @02:55AM (#4060077) Homepage
    There have been several [sourceforge.net] attempts [gyve.org] based on GhostScript [wisc.edu] to produce a real postscript API for X11.
    • Those are Postscript interpreters. This effort seems to be about creating Postscript-like APIs for a C library (paths, pens, curves, etc.), similar to what Java2D is for Java.

      Lots of people would like a Postscript-like graphics model accessible from C, very few people apparently want a Postscript interpreter to do their graphics (I certainly don't).

    • A vector graphics display API sure, but why postscript? Why not an open standard, like SVG?

      OK, so you can dump your screen to your (postscript) printer. Would there be problems accurately converting SVG to postscript?

      Why should the printer drive the display anyway - isn't the tail wagging the dog? Is the argument that technology should adapt to the device capable of producing the highest fidelity output?

      Maybe it's also time for printers to start speaking SVG.
  • by g4dget ( 579145 ) on Tuesday August 13, 2002 @02:57AM (#4060082)
    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.

  • Great! now that I've got enough hardware to run postscript in real time, maybe its time to do this. Anyone else remember how slow a sparc station 1 was doing postscript? At least you had thouse cool round buttons. Too bad postscript has a real problem doing the shaded bar things that seem to be everywhere now.
  • 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.
  • by Animats ( 122034 ) on Tuesday August 13, 2002 @11:32AM (#4062240) Homepage
    PostScript was a good idea that lost out for a number of reasons, most of them political. Remember when Type I font format was a secret? Apple's fights with Adobe? Adobe pushed too hard, and we ended up with TrueType.

    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.

  • 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.

Brain off-line, please wait.

Working...