minshall@kinetics.UUCP (Greg Minshall) (08/02/89)
First of all, I am at the very least modestly inclined towards Smalltalk, if not an outright supporter. Next, I am really not particularly knowledgeable about graphics (I barely know what anti-aliasing means, for example). I recently bought the new, 1989 edition of "Smalltalk-80, the language" and am very depressed at the graphics used to illustrate the book. Straight "lines" that are jagged, primitive representations of insects or other images. None of these are representative of the graphics possible on good, state of the art workstations (such as a Macintosh, a PC with a VGA card, a Sun, etc.). In fact, the graphics in the book are so poor compared to other modern systems that it seems quite embarassing. If these represent the best Smalltalk can do (which is unlikely) then it seems important that someone figure out what needs to be done to do things better. If these do *not* represent the best Smalltalk can do (which seems likely), then the best Smalltalk can do should have been used in the manual. The impression any casual reader is going to get is that the graphics used *are* the best Smalltalk can do, so the best should have been used. (The form and bitmap editors which come with PP Smalltalk are similarly poor at producing graphics of a quality similar to, say, MacDraw. I don't remember seeing similar tools in the Digitalk Smalltalk, so I don't know if they are also produce low-resolution graphics.) My guess is that the graphics that are used are easy to generate with the system, and represent the state of the art *as delivered to the typical end user*. I submit that the end user deserves (and, worse, expects) more. If Smalltalk is going to grow, it needs to compete graphically with the systems of today, not those of a decade ago. (In fact, the graphics are strikingly similar to what I remember of Apple II graphics.) Greg Minshall Kinetics/Excelan/Novell minshall@kinetics.com 1-415-947-0998
Knight@scs.Carleton.CA (Alan Knight) (08/04/89)
The graphics in the Smalltalk book (I expect, I haven't seen it) represent what is delivered to the screen of the typical user. Since the resolution of printers is much higher than that of the screen, they look very poor on paper, especially if magnified. Whereas packages like MacDraw send postscript to the printer, which defines things in terms of shapes rather than bits, the output looks very good. In Smalltalk (both /V and -80 I believe) the only printing facilities for drawings I have seen simply print the bitmap form rather than the actual shapes. There is no reason why this has to be done that way, and I have vaguely been thinking of doing something like it when I have some free time, as it would be useful for a project I am working on. I expect that it even has been done somewhere, it just isn't in the base system. You're certainly right that it ought to be.
peskin@caip.rutgers.edu (R. L. Peskin) (08/09/89)
> >If Smalltalk is going to grow, it needs to compete graphically with the >systems of today, not those of a decade ago. (In fact, the graphics are >strikingly similar to what I remember of Apple II graphics.) > >Greg Minshall Kinetics/Excelan/Novell >minshall@kinetics.com 1-415-947-0998 Well Stated! The need for the Smalltalk community in general, and the vendors in particular to address "real" graphics (not just windowing issues) is critical to the future of Smalltalk. We are working on this problem, and have written 3D graphics packages in Smalltalk that use real graphics (such as those found on the Ardent Titan). The implementation currently requires use of user added primitives, and lots of co-operation from the workstation mfg. But I feel we have shown that real graphics are possible in Smalltalk, that is real in the sense of being usable by the scientific community. --dick peskin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Richard L. Peskin CAIP Parallel Computing Lab CAIP Center CN - 1390 Rutgers University Piscataway, N. J. 08855-1390 net: peskin@caip.rutgers.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -- goodby