bzs@bu-cs.BU.EDU (Barry Shein) (02/08/88)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) >For high-performance high-end graphics, particularly 3D, programmability (which >is what you seem to mean by "extensibility") is totally inadequate. You don't >get performance by downloading a program that implements a rendering pipeline, >you get performance by using the rendering hardware built into the server. At >a minimum, this requires that additional "primitives" be added to your language >(you can argue about how high or low level the primitives should be), which >cannot be written directly in that language. (Note that this is true, e.g, of >video output as well.) Beyond that, it may be desirable to provide a fuller >integration of 3D-ness into your imaging model. Of course, PostScript only has >2D CTMs ... I'm not sure that 3D graphics implies rendering hardware which operates within the server. It certainly will occur, but it seems to take the discussion off on a different tack: How do we design servers and client/server protocols such that they can best take advantage of entirely new hardware opportunities. Agreed, given that you need a new primitive in most cases (and in X, Postscript and Layers for that matter it involves the same basic thing, somehow get more primitive code into the server to abstract the new feature across the protocol.) What I believe the original note was referring to was the ability to minimize traffic across the link even with complicated changes going on in the view. I agree that 3D is not a particularly good example as the image is still MxN pixels whether it represents a 2D or 3D object, 3D is an illusion on CRT's and computing new images is always a computational problem somewhere. The real issue is what opportunities are available to split processing between a client and server in various window systems. I can see the appeal of being able to say "look, you dumb server, here's how to rotate one of my objects on the Z axis" and then later say "remember I told you how to rotate things on the Z axis? Good, rotate object #7 30 degrees, thank you". It gets into a much, much deeper issue of balancing distributed computation and whether or not that will be the important thing in the future, and to whom? Large Universities (for example) will tend to have large, fast compute servers available to them. High-powered engineering firms are very likely to see everything they need on their desk ("desk-top supercomputers") rather than getting involved with shared compute servers. They may not be as fast as Crays, but they will be dedicated to their problems. Finally, home owners will only have their lone PC (which may be 20MIPs and 10MFLOPS), so distributing computation to an interpreter is of little interest except perhaps if the paradigm of the interpreter is useful. Hmm, perhaps this discussion needs to walk a little before it begins to run... -Barry Shein, Boston University