Search
An Editorial Board Meeting took place on 19 December to review progress with the Graphics Newsletter, and to plan for future activities. We are pleased to report a steady stream of new subscribers to the Newsletter and we welcome all new readers! Certain economies are having to be made in the production of the Newsletter - these are covered in more detail below. In particular, this will involve us in moving to a bi-monthly publication, beginning with this current issue. However, there will be more space available in each issue. Previous restrictions will no longer apply. We are planning to use this additional space by having sections on Books of Interest (Reviews and useful books to read), Standards, Graphics Activities at Universities and Polytechnics, and Visualisation. In addition, there will be opportunity for longer articles on general topics of the kind that have already been published (e.g. the current article on X). However, we can now plan to include such longer articles in one issue. This should make the Newsletter more readable and more attractive! We therefore invite readers and potential writers to make the most of this opportunity.
SERC is facing some difficult financial times over the next two years. In the current year, a £7M overspend is forecast and in the year 1991/92 the situation will be much worse. In consequence, there has been a ban on recruitment within SERC and measures introduced to reduce expenditure.
To even up the workload on staff and make economies in expenditure, we have had to reduce the frequency of the Engineering Computing Newsletter and the Graphics Newsletter to once every two months. The Graphics Newsletter will appear on the even months and the ECN on the odd months. During the year, we will ask readers to indicate which of the two they still require.
An advantage for the Graphics Newsletter is that we will be able to ease the restriction on space which currently restricts the Graphics Newsletter to just 4 sides.
We regret this change in frequency of appearance but it is unavoidable given the constraints under which we are working.
Once again I would like to say that AGOCG is open to suggestions for future work areas which are worthy of further investigation. These might include software developments, evaluations of products and services, purchase of equipment, etc. No project is too small to be included. This article is intended as an update of some of the areas of current activity and I am keen to be made aware of those new items for possible inclusion. This offer is open to you all. I await your input into this important area of our activities.
Work is currently in progress at Rutherford Appleton Laboratory to produce an evaluation package for PHIGS. This is planned to include a suite of programs to measure the performance of a PHIGS implementation and a questionnaire to assess the quality, richness and coverage of the implementation, to identify any extensions to the PHIGS standard (and their relationship to the emerging PHIGS PLUS extensions) and to discover any limitations in the implementation.
The performance suite includes programs to measure vector drawing speed (2D and 3D), text drawing speed (3D) and to investigate the behaviour of the PHIGS implementation in producing the same picture but using different structuring strategies. These structuring strategies cover putting the whole picture into a single large structure, and dividing the picture into a large number of small structures several levels deep. Further programs will be produced to study the effect of editing these different structures. It is also hoped to include a separate more complex structure hierarchy and to measure the speed of drawing this.
A set of test routines have been developed at the National Institute of Standards and Technology in the US and these will also be investigated.
It is hoped to assess SunPHIGS, Figaro and the products from Westward Technology and GTS-GRAL. Are there any other implementations that should be assessed? The results will be produced as an AGOCG Technical Report. Contact Dale Sutcliffe (dcS@uk.ac.rl.inf) for more information.
The following Technical Reports are available:
Contact Anne Mumford for copies.
An evaluation of the UNIRAS USEIT product has been carried out by Lakshmi Sastry. Please contact her for a copy (L.Sastry@uk.ac.rl.inf).
I am trying to assess the interest in the new UNIRAS AGX product. AGX is a high level X-windows graphic toolkit which will offer compatibility with the existing FGL and AGL Fortran libraries. It can only be accessed through a C program. It has full X windows support including multiple windows, user resizing, multiple colour tables, X event handling.
The software has optimised X graphics output for image data, polyline, linestyles, line thickness, etc. Although it can co-exist with various graphical user interfaces, UNIRAS have focused on Motif and will offer example Motif widgets. The AGX procedures are called from programs written in C which call X procedures. Please let me know if this sounds of interest to your site. The software is likely to be available on V AXNMS, Sun, DEC/ULTRIX, Convex/Unix, HP9000, Silicon Graphics Iris and Apollo machines.
Please let me know whether you are interested in the following: GKS-3D implementation; GKS source code; translators between IGES and DXF files and CGM. I can then keep you informed when more information comes up on the GKS implementations. I am trying to assess interest in the CGM converters.
As a result of encouragement by AGOCG, tools for generating, converting, viewing and plotting Computer Graphics Metafiles (CGMs) have been developed. This system, called RAL-CGM, has been developed by a team at the Rutherford Appleton Laboratory from a system written by them over the last two years. RAL-CGM is now being made available to the UK academic community (Research Councils, Universities and Polytechnics) free of charge.
The system, written entirely in C, consists of a main program and three groups of modules:
In addition, there are a number of utility modules that are used by the main modules.
The RAL-CGM system allows CGMs of any encoding to be converted to any other encoding. It also allows any CGM to be viewed or plotted on any supported device. For example, a CGM may be converted into PostScript format so that it can be plotted on a PostScript plotter. CGMs may be viewed on any X-windows device, the user being able to use buttons or the keyboard to view pictures in random order.
This first release (1.00) contains a limited number of interpreter modules, and others such as HPGL and Tektronix 42xx are being developed for the second release.
RAL-CGM has been installed on many systems, and release 1.00 will be configured for use on:
Work is already in hand towards a PC (DOS 3, Microsoft C) version that will be part of the second release.
RALCGM for VAX/VMS provides the same functionality as on UNIX machines. CGM's can be converted from one format to another, output as PostScript or viewed under DECwindows. The X windows viewer for use with DECwindows is a pure Xlib based package and so is not actually restricted to DECwindows.
The system is distributed in source form, complete with installation and tailoring command files and help files for each system. It is part of the design aim of the system that people wishing to write interpreters for other devices will be able to do so; a skeleton interpreter is included. Enthusiastic implementers should however note that the interfaces to the utility modules - which provide emulation of filled areas, text and font facilities and the complex primitives - will not be stabilized until the second release.
RAL-CGM is being distributed by the following routes:
RAL-CGM for Unix can be obtained either on a tape or over the network. To obtain it over the network, send a mail message to netlib@uk.ac.ukc whose body contains a single line:
send encoded.tar from ralcgm
You should receive a number of big files and a single small file which contains a script and instructions to glue the separate files back into a large file (the size of which will be around 1.4 Mb). Name this, say, TARFILE, then
uudecode TARFILE
should produce a file called tarfile.z (Warning: some Unix systems do not have the uudecode command. It is hoped, however, that every installation will have at least one machine - Sun for instance - that does).
zcat tarfile.z > ralcgm.tar
will generate the original tarfile (the size of which will be around 3.5 Mb), which can be split into directories and files in the normal way, i.e.
tar xvof ralcgm.tar
To obtain RAL-CGM on a tape, send a QIC24 cartridge (any length) to:
Dr Tim Hopkins,To load the software:
tar xvof/dev/rst8
RAL-CGM for VAX/VMS can be obtained over the network with the following VAX command:
%TRANSFER/CODE=FAST UK.AC.RL.VE::RALCGM1.BCK RALCGMl.BCK RALCGM DISTRIBUTION
This will fetch a copy of the VAX/VMS saveset called RALCGM1.BCK from a VAX at Rutherford.
To install RAL-CGM from the saveset:
%BACKUP/LOG RALCGMl.BCK/SAVE/ SELECT=[RALCGM...]*.* [...]
This will unravel the saveset into the correct directory structure. It will contain a file called README.VAX which gives instructions on how to complete the installation.
RAL-CGM version 1 uses the UNIX/C language command line interface so options are preceded with a minus sign, rather than in the normal VAX/option form. See the help library for more details of the options and the format to use.
The role of the window manager may help explain X further. Many window managers are available all looking different, but sharing many characteristics. A window manager is an X application. It is a client of the display and the server for other applications. It acts as a multiplexor for the output from the applications and a demultiplexor for input, directing it to the appropriate task. It provides support for cut and paste.
Look and feel is a property of the application. So the window manager as an application has a particular look and feel (clicking on a certain area will give a specific affect, for example), but that look and feel is not necessarily shared by your applications.
Common to all X implementations is the low level XLIB library. All X applications are expected to be written in C and XLIB is little more than a mapping of the X protocol onto C. X is described as device dependent by its protagonists, however this is hardly true. Instead the application is able to discover the window size and type of display (monochrome or colour via a look up table, for example) and then behave accordingly. Further, with multiple applications sharing limited hardware resources (such as colour look up tables), applications must follow certain rules documented in the ICCCM (Inter-Client Calling Conventions Manual) to prevent them interacting undesirably with one another. XLIB does not enforce these rules.
Even X enthusiasts accept that XLIB is not a good base for building user interfaces, for which a toolkit is needed. Such toolkits are based on the Xt toolkit originally developed by MIT. Sometimes considered separate are the widgets that give a particular look and feel to applications built with the toolkit. Note that the use of a toolkit does not obviate the need for XLIB. Instead only limited use may be made of XLIB, but there is no check that use falls within the rules, some of which are obvious, but others obscure.
The toolkits go some way to giving a defined look and feel, but use must be made of the additional information in the appropriate style guide manual. X will not support every user interface and the restrictions are not well documented so a user interface may not be defined in abstract Instead considerable attention must be paid to detail, such as maintaining windows in a hierarchy.
The toolkits all provide roughly similar functionality, but the look and feel of that functionality is a major issue. The difference between one look and feel and another is like the difference between one editor and the next, they all do a similar job but are the subject for much heated debate. Recently a working party of CFT AG (the Computing Facilities Technical Advisory Group) looked at this problem and made the unanimous recommendation that OSF Motif should be the usual toolkit choice. This decision was hardly based upon technical considerations but instead on the position of Motif as the industry leader. Motif comes with a window manager, MWM, and a style guide. It can be licensed by educational institutions on favourable terms.
Even with a toolkit, the building of an X user interface is a tedious job involving a surprising amount of code. Application builders exist, but are more commonly called prototyping tools. These tools allow the specification of a screen layout using a drawing program. Buttons, menus and other interaction components are placed on the screen as required. A C program is then automatically generated which will layout the screen as required, with the application writer having to supply the code for the actual application actions. Such tools, when mature, will make the building of interfaces relatively simple. Their current designation as prototyping systems belies their current lack of support for the complete development cycle, including maintenance. However, systems are improving all the time and it may already be realistic to build and maintain applications using these tools. One such system, UIL (User Interface Language), is available as part of the Motif suite.
Desktop applications are available with X.desktop from IXI Ltd of Cambridge being a leading product.
Porting FORTRAN graphics programs to X may be very difficult, though it may just be a matter of selecting the X driver of your favourite graphics package.
In a device specific application where little processor time is used, it is possible to regard X as just another graphics device. There is machine dependent work to make FORTRAN call C and a small amount of C work is also required. Other tasks that an application must perform, like repainting a window which was formerly obscured and is now exposed, can be done as part of the normal command loop. This approach makes only limited use of X and the result, which may be acceptable, is unlikely to be of the highest quality.
Replacing the text based interface of a program with a long solution cycle by a high quality graphical interface using X is a considerable undertaking. The application may need to be split into more than one task. Each menu, slider or other interaction component takes perhaps 40 lines of C. The most important advice is not to rip out your text interface - you may still want to run in batch or use command files!
ANSI X3H3.6 (a subcommittee of the US computer graphics standards committee) is working on a standard for the X (11.3) protocol and its semantics. The work, which is little more than the rewriting of MIT documents into the form of standard, will be completed early in 1991. The US work: was recognised by BSI, for the UK, as being timely over a year ago and this was subsequently endorsed by ISO/IEC ITCI SC24. The completed US (ANSI) standard will go to ISO/IEC JTC1 on a fast track with the international standard being completed very early in 1992. There is one piece of new work: in the standard, Part 4: the OSI mapping, which the UK requested. This is still the subject of lively debate in which UK experts have been heavily involved. JNT and the Rutherford Informatics Department have been particularly active in drafting documents and funding the necessary prototyping and evaluation work. An agreed solution is nearly complete and the OSI mapping should be finished at the same time as the rest of the standard.
An EWOS (European Workshop on Standardization) Technical Report is being prepared to recommend on the use of X with other OSI layers. JNT have funded an implementation which will allow existing X applications to run over OSI without recompilation, using commonly available transport level implementations and a bespoke skinny stack for upper layers. This should result in the early delivery of efficient products.
The X Consortium is funding work on a conformance testing suite for X servers. This goes far beyond what has ever been done before for a graphics standard. Verification will not only be operator based (how the picture looks and the system responds) but also objective in part (whether the correct pixels are lit). The situation with X applications is less good since display independence is largely a matter for the application which will not be readily testable. Many current applications are deficient in this respect, coping properly with only one or two display types.
Work is going on in the US in the IEEE P120l committee on standardizing XLIB, the low level programmer interface to X. The current specification is well defined but is wholly C based and there is considerable pressure for interfaces to other languages like Ada. IEEE Pl20l has also done work on window toolkits and user interfaces. Although there has been agreement that the toolkit work be based on the MIT Xt toolkit, little progress has been made because of the powerful commercial interests involved with different versions of the toolkit.
X was not designed with low network usage in mind. However, for a typical text application, bandwidths are not necessarily high: the overheads of X are not excessive. So, for example, 19.2Kb is satisfactory in some instances, but the use of images or complex graphics can rapidly increase the bandwidth requirement by a factor of 100.
This does not tell the whole story. Since echoing is performed by the client (X application) on a key press by key press basis. This means that delays from the server to the client and back must be low (of the order of 0.1 seconds) to produce an acceptable interface. In fact X can send much more information than every key press. For example, the mouse can be tracked to allow painting programs to be implemented. These large volumes of input are usually suppressed under control of the client.
In addition there is a huge demand for context switching. For each interaction, typically a single key press, the window manager process must be activated twice (once for receiving and once for echoing) and the application once. An X host will not support many servers.
X can draw two-dimensional graphics in a reasonably efficient manner. However, X has a real problem with interactive graphics. X has no coordinate system other than the pixels on your display and there is is no provision for a vector display list in the server. This means that even a trivial operation like a zoom or repairing the damage caused by erasing a line can require very extensive communication. X is a considerable step backwards from EmuTek in this respect.
X output is tied to pixel values of limited range so screen copies are not of a quality suitable for publishing and I know of no hardcopy devices that use X. The graphics user would not be advised to use X directly, but instead a device independent package that will also support CGM and Postscript (or HPGL), for example. X drivers for the device independent graphics standards: GKS, GKS-3D and PHIGS (and for the proprietary GHOST, GINO-F and UNIRAS) are becoming available. PEX (PHIGS Extension to X) is being developed by SUN for the X Consortium, providing the three dimensional support and server display list required for a fast PHIGS implementation.
The latest version of X has high quality Bitstream based fonts, but fonts are not specified as part of the X protocol and are selected by name. What a server does, when asked to display a font it does not know about, varies. On a workstation a server may use NFS to look at a fixed place in the shared filestore to find the font. In other cases the server uses Unix ftp or tftp to a configured place to locate it. These mechanisms are not always appropriate, for example in an OSI environment. Another problem with fonts is that they are not currently scalable and work is being done to add this functionality.
There is much information about X on the networks and the X sources are held on the Imperial College information server. These contain the raw documentation in machine readable form. There is a published set of manuals on X by O'Reilly. These are available for example from IXI Ltd of Cambridge. Almost every version of Unix comes with X in one form or another and this is a source of implementation specific information. The listoflists on JANET.NEWS contains many discussion lists on various aspects of X.
X is in many ways a flawed system with a number of problems, many of which are not hard to identify. However it offers important functionality for the operation of distributed systems. Its lack of real competition means that it will be with us for many years to come. The commitment of industry means that it will continue to be improved to meet the changing requirements of the years ahead. If it only reduces the babel of terminal protocols it will have performed a worthwhile task!
The Scientific Visualisation Group at the University of Leeds was formed on 2 October 1990 with the following objectives:
Although most members of the Group are from science and engineering departments, we are currently exploring links with arts departments. The Department of Fine Art is interested to use visualisation tools for creative applications. We hope that, in turn, such creative and artistic talents will be of benefit to the scientific visualisation community in the presentation of their images. Such cross-disciplinary ideas should be to the benefit of all.
We welcome input and ideas from other Computer Centres.
Scientific visualisation is an important area - with lots of new tools already available. For example, KHOROS consists of 350,000 lines of C code and contains extensive facilities for scientific visualisation, signal and image processing.
Output on to video is becoming increasingly important - to capture real-time information on simulations etc. Staff and researchers need this output for demonstrations at conferences or to secure research funding. There is a lot of experience of handling video and creating artistic images in TV Centres. This is extremely valuable to the scientist and engineer in their scientific visualisation work.
Developments in multi-media emphasise the importance of integrated tools. This requires interested departments to cooperate in order to get the best results from existing resources and avoid duplication of effort.
If you wish to join the email list, or receive more information, please contact the undersigned.
A Conference devoted to exploring how visualisation is being used to extract knowledge from data was held 23-25 October, 1990 in San Francisco. VISUALISATION'90 was the first full Conference to concentrate on the topic of visualisation. The Conference consisted of tutorials, case studies, panels, demonstrations and refereed papers.
Scientific Visualisation (SV) is a relatively new and emerging area of science and engineering. The field of scientific computations is advancing tremendously. Supercomputers, new hardware architectures, and advanced techniques in software are allowing for increased complexity of mathematical models and simulations. This results in a closer approximation to reality, which enhances the possibility of acquiring new knowledge and understanding. In addition, large collections of numerical values are being produced and collected. Satellites, radio telescopes, geophysical sensors and medical scanners are all examples of sources of huge amounts of scientific data. This data contains a great deal of information. The problem is to convey all of this information to the scientist so that effective use can be made of the human creative and analytic capabilities. This requires a method of communication with a high bandwidth and an effective interface. The human vision system and computer-generated images are used in SV. Images with colour, intensity, transparency, texture and a myriad of other techniques can, if properly prepared and properly interpreted, convey a tremendous amount of information in a short period of time. SV holds great promise for the future. The goals are to aid scientists and engineers in their efforts to better understand the physical world, which ultimately leads to an improved world for all.
After a day of tutorials, the Conference began with a keynote speech What is This Thing Visualisation? by Gordon Bell of Stardent Computer. This was followed by a panel session, Towards Visualisation 2000 - The Next Ten Years. This keynote panel brought together four corporate leaders to discuss the future of Visualisation. Panelists J. Clark, Silicon Graphics; Stephen Colley, NCUBE; D. Nagel, Apple Computer and J. Poduska, Stardent Computer addressed research, hardware, and applications issues whose solutions are critical to future progress. They analysed key problem areas and made predictions about future hardware. Six additional panels were scheduled in the following two days. Their titles give some indication of the diversity of the the topics covered:
Rather than have a continuing vendor display area, a single block of time was set aside solely for demonstrations. Research organisations and commercial companies presented state-of-the-art software and hardware for visualisation.
A case study is intended to deal with the interdisciplinary issues of visualisation and how to progress from the research to the application. Nine sessions were scheduled. This unique part of the Conference covered a variety of application areas which are indicated by the titles of these sessions:
The proceedings of the Conference include the 45 refereed papers presented at the Conference. These papers represent the state-of-the-art in visualisation research and applications. The authors are from leading research centres, laboratories and universities. These proceedings (ISBN 0-8186-2083-8) can be obtained from IEEE Computer Society Press. In addition to these proceedings, a special issue of the journal Computer Graphics and Applications will be devoted to this Conference. The May, 1991 issue of CG&A will include updated and revised versions of some of the best and most representative papers presented at the Conference. The titles of the papers selected for this issue indicate the breadth and scope of the topics covered:
Due to the success of VISUALISATION '90, a sequel conference has been scheduled for October, 1991 to be held in San Diego. Look for future announcements.
