A friend asked me about the history of Display PostScript, which Jack Newlin and I wrote together with Adobe when I was at NeXT. I thought I might as well post the reply where people can comment on it!
-----------
Sure, I've forgotten most or all the proprietary stuff I knew back then :) besides the key proprietary element was what we now call Type 1 Fonts -- they (Adobe) decided to publish that stuff a few years after I left NeXT.
Basically, we actually made the window server a PostScript interpreter, and sent over a binary-encoded form of actual PostScript calls. To get efficiency out of it, we created new PostScript operators that were array versions of many of the calls so that you could draw more per primitive, but you were still sending a program to the sever that was interpreted by the interpreter.
There was one PostScript thread per connection (kind of obvious) plus some thread to handle user input. And of course, all of the windowing operations were implemented as new PostScript operators (newwindow, movewindow, sizewindow, etc., etc.). You could supply PostScript callback procedures to be called on user events in your window to filter, process, or do whatever to them (including passing them back to the client). The model was very similar to Sun's NeWS server, which we were influenced by, but they put a lot of emphasis on doing much of your application event-handling in PostScript, whereas we regarding PostScript-level event handling as the outlet of last resort (I gave a talk at SIGGRAPH once called, "Why PostScript is my least favorite programming language").
Obviously, picking PostScript defined the 2D graphics model pretty clearly. The other wise choice we made was to choose Porter-Duff compositing as the basis of all image combination operations supported by the system. That allowed programs to be very independent of the framebuffer depth and provided a much more powerful layering system as well.
Frankly, though we got it all working pretty well, I don't think actually using a language interpreter was the right idea. I think the stream-of-asynchronous-procedure-calls model, as implemented by X or by OpenGL among others, is a better model for that kind of performance- and memory-sensitive interface. I still think PostScript was a great (2D) graphics model, so we chose correctly there -- it's just that with 20-20 hindsight I would have defined a procedural interface with a clear mapping to PostScript, but which wasn't directly tied to a language interpreter.
Peter Graffagnino, who took over for me when I left NeXT, certainly thought so -- in Cocoa, that's kind of it works. There's a DPS procedural layer, and it's not subject to redefinition by the window server's PostScript interpreter, which allows a more efficient interpretation of the protocol stream and a lighter memory overhead. You can still pass PostScript down to be interpreted a drawn, but that's not the usual interface to the window system.
Hope that helps!
Leo
On Jan 7, 2006, at 12:11 PM, Justin Ryan wrote:
hey leo, i noticed on your website that you worked at NeXT on
DisplayPS technology. I'd really like to chat with you about this, if
your knowledge of the technology is not overly proprietary. I mostly
want to understand more about this, as I've seen that a number of
f/oss projects are striving to move the f/oss user interface into the
new world of non-x11 display drivers on unix.
:)
3 comments:
Interesting stuff, Leo - thanks for taking the time :)
It does seem logical that having a language interpreter as an integral part of the graphics system could be a tad heavy, and I remember reading at some point about how PS was designed to be a language / format and also a directly accessible API.
I was reminded, when reading the names of he new operations, that the concept of 'windows' is also getting boring to me lately. I wonder if one could define, based on vectors, a 2d zone and even allow for some inter-app negotiation of screenspace, esp with alpha. It's always sort of bugged me that everything is a rectangle, and people sometimes push that limit in a singular app to create a cool interface - my current favorite on the mac being iPulse. You can style the window, hide portions of it, etc.. - but it's always a rectangular window. At the risk of sounding reckless, I'm thinking with a gig or so of ram I can maybe afford to store a couple of extra coordinates per ui context, and that ps could help make such a thing either easier or more robust in implementation. :)
I guess I'm not quite familiar with the internals of x11 -- or OpenGL, for that matter -- enough to understand how exactly they use a stream of async calls, but it sounds like a powerful concept. In fact, now that I think of it, I wonder how this all ties into OpenGL, since, afaik, that is how the interface is ultimately drawn on OSX.
Can you point at any info on Sun NeWS server, or is this too old to be on the web? It's definitely not an easy google search to sift through.. ;d
Yeah, finding NeWS information is pretty hard now. I found one of Don Hopkins' old posts at http://www.donhopkins.com/drupal/node/64 where he summarizes some of the key differences between NeWS and DPS (I agree with his description of the differences and disagree about which one is the more desirable ;-).
interesting, so NeWS is actually part of Sun X11.. very much antithetical to what I'd like to see. One thing I really like about OSX is that my native apps are native, and X11 is a cross-platform, networked window server, as it was designed. If I don't need that, I don't have to buy into it for basic GUI.
Post a Comment