Efficiency is a clear pre-requisite for making graphing packages more intelligent. Interactivity depends upon the number of frames one can display per second while additional computing is only possible when both the basic computing of objects and their display can be done efficiently.
     Let us define the display response time to be the time a system spends from the start of processing a plotting request until the respective mathematical object is rendered on a user's display. In order to achieve effective direct manipulations and/or smooth animations, it is essential that the display response time for an object be small enough, say less than 1 second for interactions and less than 0.1 seconds for animations i.e. 10 frames per second.
     Interactivity being our purpose, we will limit our investigations to methods which will ultimately lead to some kind of interaction with the graphics on todays workstations and desktop computers. We will also limit our considerations to explicit curves and surfaces. That is, curves defined by x=f_x(u), y=f_y(u), z=f_z(u) and surfaces defined by x=f_x(u,v), y=f_y(u,v), z=f_z(u,v), where f_x, f_y(u), f_z(u) are closed-form mathematical expressions composed of analytic functions like the rational operations and the exponential, log and trigonometric functions. Although mathematically very similar, curve and surface plots are quite different with respect to their display response time. Many more data are needed to get a reasonably accurate mesh representation of a surface than is needed for a curve. If we consider a naive plot of a surface defined over a 50x50 grid then 7,500 data points have to be manipulated. This is almost two orders of magnitude large than an equivalent curve plot.
     Assuming the common model of plotting systems which we discussed in the introduction, the display response time can be subdivided into the object computation time - the time it takes to compute the numeric data points of an object, given its mathematical description; the communication time -the time it takes to translate the generated data into an intermediate representation and communicate this representation to the graphing part of the system; and the rendering time - the time it takes to actually render the intermediate representation on a user's display.

Object Computation

     In naive plotting algorithms, curves and surface are computed by straightforward evaluations of the expressions defining the object. In most cases, this bottom-up recursive interpretation of expression trees results in poor performances.
     Consider the columns Maple and Macsyma in Table 1. Not only does it takes seconds to compute simple surfaces, but even computations of curves usually take much longer than 0.1 seconds. Besides inefficient computational methods, this is mostly due to inefficient routines for floating point array manipulations. For example, although Maple's evalhf function uses hardware floating point routines for efficient evaluations and array manipulations, there is no support for storing arrays of floating point number are converted into Maple's internal floating point format and stored as such. Not only are these conversion expensive, but subsequent top-level array manipulations are even magnitudes slower than their C-counterparts. Most other CA system exhibit similar overheads (see also [Zim94]).
     As mentioned in 2.1 most CA systems use adaptive schemes for curve computations. However, this approach seems infeasible for surface since determining local redefinements of the underlying 2D mesh and the respective recomputations of the x, y, z values are rather complex and expensive operations. Furthermore, the irregular meshes produced by adaptive surface computation schemes are more difficult to render.
     Another technique (used for example in Macsyma 418) consists in compiling the given expressions and obtaining the evaluation data by executing the respective object code. This is a rather costly method as the overhead of generating and compiling source code usually amounts to several seconds. Moreover, such on the flight compilations are currently only possible with a limited number of CA system.

Chains of Recurrences

Communication of objects

     When two different programs are used to compute objects and to display them (which is generally the case), the communication time may become significant with respect to the computation and rendering times.
     To minimize the communication time it is important that the intermediate representation can be efficiently generated, sent and parsed. Our experience of connecting IZIC with various CA systems highlights the importance of avoiding any extraneous format translations, such as converting large amount of binary floats into ASCII and vice-versa. Consider Table2. It shows communication timings using an experimental binary extension of the ZIC format used to encode the graphic object sent to IZIC [Bac94]. We used for this experience a mesh of the Enneper surface consisting of 7500 numeric data points which is typical of a surface representation generated by a CA system.

Rendering of Objects

     With modern workstations and desktop computers, speed is usually not a problem for curve rendering. Provided an efficient implementation for objects computing, priority should definitively go to reliability and user-friendliness at it is often possible to perform in real time many more computations than required for just plotting, even using a "naive" plotting method.
     But surface plotting is quite different. Rendering times depend on the complexity og the mesh and the rendering techniques used. Given a typical mesh and using popular desktop computers or workstations, the most powerful graphics methods such as radiosity or ray-tracing can definitively not produce frames fast enough for animation or real time interaction. Less powerful methods can still produce smooth shaded images, typically by interpolating color values within each polygon of the mesh. Nevertheless, such a method works fast enough only for relatively small meshes. With slower computers, animation of complex surface objects is only possible when rendered in wire-frame mode.

Auto-selection of a rendering technique

     Several plotting packages provide a collection of rendering techniques ranging from wire-frames with or without hidden line removal to smooth shading. Most of these packages use wire-frames by default and provide menus to change the rendering method at runtime. However, the default method could be selected automatically by the program according to the object's characteristics compared with the requirements of each rendering algorithm and computer's performance. In IZIC for instance, auto is a mode in which the technique used for rendering is automatically selected according to the complexity of the mesh. Once computed, each mesh is rendered using the highest quality rendering method which yet ensures that the first image will appear within a short time. After that, the user can interact in quasi real-time with the object, or select a finer rendering technique which will very likely increase the rendering time significantly.