uad1077@dircon.co.uk (Ian Kemmish) (06/23/91)
< ..comments by Jim Gettys and others on comparing X and NeWS approaches to life ....> Apples and oranges are both fruit (unless one's a boutique in Baker St:->). There are many similarities between X and NeWS; to my mind there are more of these than there are differences. Both of them consciously ruled fairly large classes of activity out of their graphics libraries. In the case of NeWS, as Jim Gettys points out, this rules out certain imaging applications, as well as ECAD and other things that like bitplanes. In the case of X, this rules out many of the things that graphics-oriented end-users want to do, as I can testify having sweated over a Freehand-alike (that's `graphics' not `computer graphics'). [For myself, I have to say that I generally use the SGI GL library if I want to write a useful program; I slightly prefer NeWS to X though I have never written a NeWS app. for money, so I probably have missed most of the bureaucratic wrinkles in using it. Thus, I regard myself as reasonably neutral.] This intermittent X vs. NeWS argument always seems to miss the point, which to me is that both of them are pretty restrictive, and currently, both of them are gas-guzzlers. It's intolerable that simply switching windows should take 10-15 seconds on a machine which the adverts claim is 15 Mips. [That's a figure for X+Motif by the way, I'm told that Openwindows is just as bad.] It's possible to do better - when workstations were ~1 Mips it certainly didn't take three minutes to switch windows; and with my minimalist NeWS-ish clone that I use at home anything above a second starts to worry me (not that I'm claiming that's of merchantable quality; I use it because it's small and the PS in it is at least real PS!). At the Eurographics workshop on window management in 1985, James Gosling pointed out that he had chosen PostScript principally for historical reasons, that it ought to be feasible to do the same thing with other standards, and it would probably be useful experience if someone were to try. (Unfortunately the X people either didn't attend this or didn't say anything that got into the proceedings.) After all, there are only half-a-dozen things you can actually *do* with a window, it's mainly a matter of fixing on a suitable binding for the graphics language you're using.... isn't it? The people who read this newsgroup have at least by that action indicated some open-ness of mind about window managers - whether their predilection is for NeWS or X, or like me, for neither really. What I'd like to see is some discussion starting up of how we can actually deliver some of the oomph in these workstations to the man in the street. I don't see that endless extensions to X are necessarily the best way to do it, other than simply because it is the standard way to go. The key idea behind the extensions - of a variety of graphics libraries - is correct. However, by the time you get a 2D drawing library, a 2D imaging library, a DVE video library, a 3D surface rendering library, a 3D volume rendering library, and so on, things are getting pretty big. These days, the companies and organisations who are pushing the window systems are also the companies pushing the operating systems -- it ought not to be beyond the ingenuity of man to get the to add features to the OS's to support more advanced designs of window systems, whatever they are. Maybe something to support closer co-operation of processes, maybe full-blown threads, I don't know. In the advance of gas-guzzling software, I fear a return to the 70's attitude of viewing software as a way of selling hardware *add-ons*. ``Is your [***] running slowly, sir? Don't worry, here I have an extra 16 Mb of memory at a special knock-down price for this month only....'' where *** <-> APL or VSPC in the 70's, and GUI in the 90's. Perhaps we could persuade the manufacturers that they could use software to sell *complete* machines by increasing the gee-whiz factor in the showroom? I have this nagging feeling that when the Japanese do decide to target the desktop computing market, that is the kind of approach they are fond of.... -- Ian D. Kemmish Tel. +44 767 601 361 18 Durham Close uad1077@dircon.UUCP Biggleswade ukc!dircon!uad1077 Beds SG18 8HZ United Kingdom uad1077@dircon.co.uk
bmacinty@mud.uwaterloo.ca (Blair MacIntyre) (06/24/91)
>>>>> On 23 Jun 91 13:37:07 GMT, >>>>> In message <1991Jun23.133707.3366@dircon.co.uk>, >>>>> uad1077@dircon.co.uk (Ian Kemmish) wrote: Ian> Both of them consciously ruled fairly large classes of activity out Ian> of their graphics libraries. In the case of NeWS, as Jim Gettys Ian> points out, this rules out certain imaging applications, as well as Ian> ECAD and other things that like bitplanes. I don't understand this. If I create a Dynamic Colormap in NeWS, I can allocate colormapsegments from it in such a way as to give me the ability to play with bitplanes. What are you guys talking about? What am I missing? After all, the simple little Fader demo uses bitplane animation. To steal a bit from the header of the fader demo: % % Fader uses colormap double buffering to get its results. 4 pixels % are allocated by asking for 1 cell and 2 planes. combining this one % cell with the 4 possible plane mask combinations gives the 4 pixels % used. the base cell with no planes ORd in is used as the background % for the window. the cell with either plane turned on gives the two % foreground colors. the cell with both planes turned on is the % pixel value of the combined foregrounds. % -- Blair MacIntyre, Computer Graphics Lab Dept. of Computer Science, University of Waterloo, Waterloo, ON, Canada, N2L3G1 {bmacintyre@{watcgl|violet|watdragon}}.{waterloo.edu|uwaterloo.ca}
barnett@grymoire.crd.ge.com (Bruce Barnett) (06/25/91)
In article <1991Jun23.133707.3366@dircon.co.uk> uad1077@dircon.co.uk (Ian Kemmish) writes: > At the Eurographics workshop on window management in 1985, James Gosling > pointed out that he had chosen PostScript principally for historical reasons, > that it ought to be feasible to do the same thing with other standards, and > it would probably be useful experience if someone were to try. The advantage of the PostScript stencil model, as it was explained to me, is that: 1) It is possible to have device independent imaging. B&W vs Color, high res vs low res., non-rectangular pixels, etc. 2) It supports a write-only model. The advantage of the write-only model is you can have multiple processes and/or a pipeline when writing data to the screen. XOR-ing makes pipelining the data difficult. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett