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."
Beziers. (Score:1)
I'm sorry.
Re:Beziers. (Score:2)
Didn't NeXT do something like that? (Score:1)
NeXT and NeWS (Score:2)
Re:NeXT and NeWS (Score:3)
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)
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.
NeXT (Score:1)
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)
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.
Re:NeXT (Score:2)
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)
Re:I don't understand (Score:1, Informative)
Re:I don't understand (Score:5, Insightful)
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 :)
Display Postcript/Ghostcript/Quartz/etc... (Score:1)
Someone should simply merge the SVG graphics or PDF graphics format ala Quartz into the X11 Server.
Port DE's to it (Score:1)
First is it actually better? (Score:1, Troll)
Re:Port DE's to it (Score:2)
render status now? (Score:1)
Anyway, Can i load up render and try these features out in the current X release or is this just the future...
Re:render status now? (Score:2)
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
Re:render status now? (Score:1, Informative)
Rich.
Re:render status now? (Score:2)
Re:render status now? (Score:2, Informative)
$ 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.
Re:render status now? (Score:2)
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...
So what? Still no alpha channel? (Score:4, Funny)
Why is there still no alpha channeling? What about genie effect?
how much money would it take to get this code written?
Re:So what? Still no alpha channel? (Score:2, Interesting)
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.
Re:So what? Still no alpha channel? (Score:2)
we know that, but we want to be able to run KDE and gnome. We NEED X for compatibility reasons.
Re:So what? Still no alpha channel? (Score:1)
Re:So what? Still no alpha channel? (Score:2)
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?
Re:So what? Still no alpha channel? (Score:2, Insightful)
Re:So what? Still no alpha channel? (Score:2)
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.
Re:So what? Still no alpha channel? (Score:2, Informative)
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).
Re:So what? Still no alpha channel? (Score:3, Interesting)
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.
Re:So what? Still no alpha channel? (Score:2)
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".
How will it compare to Quartz.. (Score:5, Interesting)
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.
Now thats the important question, mod him up! (Score:2)
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.
Re:Now thats the important question, mod him up! (Score:2)
Re:Now thats the important question, mod him up! (Score:2)
Re:CAN YOU GET JOBS' DICK FURTHER DOWN YOUR THROAT (Score:2)
YUM!
Billy you are next!
Re:How will it compare to Quartz.. (Score:2)
Re:How will it compare to Quartz.. (Score:2)
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)
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?
Re:Let's skip: (Score:2)
That's funny. I get at least one email a day on the gentoo-users email list with this as the subject.
Re:Let's skip: (Score:1, Funny)
Goals and intentions? (Score:5, Interesting)
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)
Must be objective-c (Score:1)
Re:Must be objective-c (Score:1)
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++?
Re:Must be objective-c (Score:2, Informative)
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.
Maybe ill learn objective C, (Score:2)
Re:Must be objective-c (Score:2, Informative)
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.
Re:Goals and intentions? (Score:5, Informative)
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.
Re:Goals and intentions? (Score:2, Interesting)
Re:Goals and intentions? (Score:2)
Re:Goals and intentions? (Score:2)
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
Re:Goals and intentions? (Score:3, Informative)
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.
What is with the NextStep obsession? (Score:1)
Re:What is with the NextStep obsession? (Score:1)
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.
(:
Re:What is with the NextStep obsession? (Score:2)
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...
Re:What is with the NextStep obsession? (Score:2)
Re:What is with the NextStep obsession? (Score:2)
There's distribution-level issues (filesystem layout and so on), but you can fake that if you need to.
Re:What is with the NextStep obsession? (Score:2, Interesting)
Re:What is with the NextStep obsession? (Score:2)
if there's such a nice API and software development tools, why was nothing ever developed with it.
Because plenty of stuff *has* been developed with it. You're just ignorant of them. For example, it has been heavily used in the intelligence industry and on Wall Street. And I'm sure you've probably heard of Mac OS X, right? Guess what the primary development platform is. You should check out Softrak [stepwise.com] and the peanuts FTP archive [peanuts.org] some time too. And maybe the OMNI Group [omnigroup.com] and some others. Is there as much software as there is for Windows? No. Is that because MFC is a superior development platform? Pffffft. It's because Microsoft has the marketing muscle and lock-in advantage (and an awful lot of luck thrown in for good measure).
And why is every application that was developed as part of it so primitive and un-user friendly.
You've never used any of this stuff, have you? There are some quite attractive and usable applications out there. GNUmail [collaboration-world.com] is very nice [collaboration-world.com], for instance, and was developed primarily by one author in a very short period of time. Are there poorly designed UIs as well? Of course. But that's the fault of those who design. And that happens everywhere--UNIX, Windows, Mac OS, BeOS, etc.
Is it just a coincidence that it was a brilliant platformed developed by people with no design sense.
I find it to be quite elegant looking. But at any rate, I was talking about the API. Y'know, stuff like Array and String classes and responder chains. Stuff you don't actually "see". How it actually looks is not set in stone. That's why Mac OS X looks completely different but is built on the same basic classes as OPENSTEP or GNUstep.
Re:Goals and intentions? (Score:2, Interesting)
Re:Goals and intentions? (Score:2)
It is. The object model of Objective-C is far simpler and more powerful than that of C++, but when it comes to memory management and exceptions, Objective-C is outdated and very cumbersome.
Objective-C needs updating to address these issues. Unfortunately, nobody seems to be working on that. And that means that Objective-C will likely slowly drift into the sunset.
For Apple, it makes a lot of sense just to throw in their lot with Java rather than develop a new language.
Re:Goals and intentions? (Score:2)
Nope. The GNUstep project has added a Garbage Collector. It's still experimental and will need some work, but it's there. And Apple is considering it as well. And the guy at Apple in charge of maintaining their gcc extensions is very chummy with the GNUstep crowd. There is work being done on merging the runtimes. It's just going to take a while for it to happen.
Is this a security hole? (Score:2)
Re:Is this a security hole? (Score:5, Insightful)
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.
Re:Is this a security hole? (Score:2)
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
Re:Is this a security hole? (Score:2)
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
-adnans
beziers (Score:4, Informative)
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.
GhostScript? (Score:3, Informative)
Re:GhostScript? (Score:3, Informative)
That's what I mean, who needs a new format? (Score:3, Informative)
Re:That's what I mean, who needs a new format? (Score:2)
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.
Re:RMS is a member of the Free Software movement (Score:2)
As far as I know neither the way NeWS or the way X was distributed would be considered truly free by the FSF.
I think getting access to NeWS required a very large amount of money and a NDA-style contract so I don't think anybody would consider this free.
My understanding of X is that you were not allowed to do anything unless you paid the $100. I think this violates the rules of the FSF for a true Free software (because it limits the ability to redistribute the source code) but for a lot of people this would be considered reasonably free.
Re:RMS is a member of the Free Software movement (Score:2)
I am not sure of the actual requirements of X, that is just what I seem to remember.
Re:That's what I mean, who needs a new format? (Score:2)
Re:GhostScript? (Score:2)
Why? (Score:2, Interesting)
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)
" 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). "
Re:Why? (Score:2)
I hope this have a better fate (Score:5, Informative)
Re:I hope this have a better fate (Score:2)
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).
But why postscript? (Score:2)
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.
it doesn't seem to be Display Postscript (Score:3, Insightful)
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.
NeWS is back? (Score:2)
I hate Bezier splines with a passion... (Score:2, Informative)
Look into it.
PostScript Everywhere, not (Score:3, Interesting)
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.
That's why Acrobat/PDF (Score:3, Informative)
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 [rlg.org]
for details).
The PDF file format is open, and many tools have been written to use it without involving Adobe.
Distributed PS - NeWS - Oak - Java (Score:2, Interesting)
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.
Re:huh? (Score:1)
Well, this project is just a hack on their idea. It's called "bragging rights"... Unless there's a better reason.
Re:Gez. (Score:3, Interesting)
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?).
Well then use Windows95 or Linux (Score:1, Troll)
Why even talk about OSX if you dont like its best features? its eye candy and flash are what seperates it from linux.
Re:Well then use Windows95 or Linux (Score:1)
Re:Well then use Windows95 or Linux (Score:1)
Eye candy is not a necessary feature of OS X. Eye candy is not what makes OS X great. What makes OS X great is that it is an extremely stable platform, with a great set of libraries and application programming standards so that everything works. That is what makes OS X so great, everything works, it's all easy to configure and setup, and you normally would never need to really touch anything. Being a UNIX just makes it all the better, and for those times that you want to go beyond what the happy-little configuration things will let you do, you have all of the power of UNIX to help you on your way.
So remember boys and girls, OS X is about being a stable and simple platform, the eye candy is marketing, how else would you get everybody to rewrite all of their applications?
Re:Gez. (Score:1)
Exactly! I think the rounded GUI of windows XP was a step back from 2k pro I don't like the way KDE and Gnome's defaut themes try to make things round, and I probably wouldn't like it in OSX, either. My idea of a UI is KDE's "Light style 3rd revision" flat, clean, fast, productive, and professional. The flat boxy UI is one of the things I like most about UNIX, it gives it an identity of it's own. It's a shame so many are trying to kill it.
Re:Gez. (Score:2)
This is not "USE XP!", I am quite sure you can get it to work like this in KDE for example. I am just saying give MacOS X own system a chance for a while and stop thinking in terms of virtual desktops, you might end up liking it (or end up switching OS).
The biggest reason I used virtual desktops was the 10+ xterms I had to have up all the time. I obviously don't have many xterms in Windows. Does you guys who use MacOS X use a lot of terminals? I'm just curious about how much of the BSD part of MacOS X is used by people.
Re:Gez. (Score:2)
For those looking for Virtual Desktops in OS X, look no further than Space.app [sourceforge.net], a GPL'd application that provides multiple desktops (configurable) and hotkeys to switch between 'em (also configurable). The concept of a "sticky" space is also supported.
As for easing the clutter on the desktop, if virtual desktops alone don't do it for you, check out Windowshade X [unsanity.com] - this brings back the functionality of being able to double-click on the title bar of a window and collapse the window to just the title bar, as in OS 9 (and most Linux WMs).
If you don't like the dock, get rid of it! [hybit.com] As for the widgets, you'll be happy to know that the various buttons in OS X have been on Weight Watchers during Jaguar's development .. check out any of the screen caps at Think Secret [thinksecret.com] to see the new buttons before Aug. 24th - while they aren't quite like the Java buttons, they are quite a bit slimmer and make the interface look quite a bit less like candy and more like a professional workstation.
Cheers!
Space.app not up to scratch (Score:2)
Re:Space.app not up to scratch (Score:2)
Even so, its quite useful
Re:This will work fine (Score:4, Interesting)
Yeah, cause they must have reverse engineered [adobe.com] 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.
Re:10 years lost (Score:4, Insightful)
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).