Much to its credit, this paper focuses on the structure and data flow of of the rendering system rather than on implementation details or applications. Unfortunately, though, the organization and presentation are confusing enough to reduce much of the value of the contribution. In fact, none of the reviewers got a firm idea of what had been done, or even what had been tried, from reading the paper. But after several readings, it is clear that there are some good ideas in this paper that need to be brought out. That was why it was accepted; this report is an attempt to help the authors express themselves more clearly and more to the point.

The biggest problem is organizational. The introduction is good, the review of previous work fairly good, but by page 6 the discussion has become a number of parallel stories being told together. By section 3, the paper is inscrutable. The presentation reveals a few ideas at a time, partly as philosophy, partly as intention, and partly as implementation details. Also, the level of the discussion fluctuates, with micro and macro levels interleaved; appels, cores, slices, formats, streams all discussed together; and functional and data-flow points of view coming and going. This confusion makes, for example, page 7 almost incomprehensible. When reading the paper, it is necessary to flip pages back and forth to follow the discussion.

It would be much easier to follow the story if it were told as a grand plan earlier, and if that plan were referred to as the details unfold. The paper probably needs a complete rearrangement. It could also use a careful reading by an experienced editor of English.

Start by explaining that you are proposing an architecture for ``display processes,'' and define what that means. State what problems need to be solved, and give enough of an overview of GRAPE to convince the reader that it might solve them — that is, that it's worth reading the paper. Also explain how much of the system exists, and how much is just design. There should be a point in the paper where the reader can stop, convinced of the point you are making and why it is important, but without having had to decode much implementation detail. After the architecture and its benefits (and drawbacks) are made clear, describe enough of the implementation to prove that the architecture is practical. In a SIGGRAPH paper, there won't be enough room to be thorough, but there should be enough to be convincing.

If the idea is to use tree-structured data flow, say so early on. But if that's really the idea, the examples don't drive it home too effectively: they're just as easily done in much simpler environments. Reread or rethink the paper, decide what the contribution is (be it a design, a way of structuring the system, the application of data flow methods to graphics, or whatever) and rewrite and rearrange so the contribution is made clear and backed up by the description and examples.

The paper is too long, but rearranging may help because the paper must often repeat itself to tie together the parallel discussions.

Some specific comments:

Abstract: In the first paragraph, ``more flexible'' than what? What is the ``process structure'' that needs experimentation? The abstract states some features of the architecture, but are they the most important? The tree structure is not mentioned anywhere. An example of the problematic terminology and exposition: the word ``nodes'' in the last sentence has no referent.

Things are smooth until page 4. Then we hit ``a semantically meaningful parameter template'' that ``carr[ies] operands between functions,'' which is quite a hurdle to clear. The next sentence then flips to Haeberli, and we are left wondering what the meaning was, let alone the functions and operands.

Section 2.3 seems out of context, and uses a number of undefined terms (process, appearance parameter, environment) to define pixel evaluators. ``Environment'' is a heavily overloaded word throughout the paper, referring to the surrounding operating system (approximately), the ``macro'' and ``micro'' worlds, their combination (``the appel evaluator environment''), and something else (section 6.3). What is a compositing environment? Please use terminology carefully, and define it helpfully.

Section 2.3.1: Are shade trees associated with pixels? Usually they are attached to objects. An important point is being made here but it is lost in the discussion of Cook's work.

Section 2.3.2 presents, while discussing Perlin, much of the philosophy underlying GRAPE. It should be described separately; it is largely what makes the system interesting. You have opinions about how to structure a system, based perhaps on Perlin's ideas, and they are the main reason for reading this paper. Don't bury them here. In particular, a major decision is made in the last sentence of the section, but it's not clear what the decision is, or what it affects.

Sections 2.4 and 3 spell UNIX differently. Choose one way.

Page 7 is hard going. The fourth paragraph begins ``So'' but ``So'' what? The wording implies there is an argument being made, but it's lost in the explanations. This one short paragraph ties together data flow, functions, data, display, specialization, testbeds vs. production environments, efficiency, and some notion of process structure. Then the next one-sentence paragraph makes a distinct point and claims it's the basic objective. You must write more clearly.

Section 3.2 and its subsections must be read several times to be absorbed. It would probably be easier going if the global data flow was explained first.

Section 3.2.4, line 6, should ``slice'' be ``span''?

Figure 4 brings out some questions: How is a complete system assembled? How are functions invoked? At the stream level? appel level? picture level? The answers to these questions should be known before descending to the detail of this figure. Section 4.1 is the first mention of the topology of the system, arguably one of the most important aspects. (It's also the referent for ``nodes'' in the abstract.) Similarly, where does the arrow on top of Figure 5 point?

``In fact, the reader probably could have...'' is bad style. Let the reader decide what the reader could have done.

Section 4.2 answers some questions, but not enough. Is there a directory per object or per structure? How does a function map to a directory? Executable code must be involved somewhere; how is it bound to the directory? The last paragraph of this section is opaque.

Section 4.3 is an unexpected burst of distributed systems stuff. How did global servers get involved? And write permission?

Figure 6 is unhelpful, and the caption contains the phrase, ``special stream format changing nodes,'' which is hard to parse.

The phrase ``pair of functions will surround every node'' on page 12 brings up again the question of how functions are bound to trees. What is the structure of the data? How is it compiled? What is it compiled from? What is it compiled to? How is it executed? What does the user see?

Section 5.1 continues to describe small parts of the missing big picture.

Figure 8 contains two graphs that are supposed to be similar, but it takes a while to see the similarities. The text could help here, as could a better caption. In particular, what makes this transformation from idea to implementation? And what are the details of this transformation?

Mentioning symbolic links here and elsewhere is probably exposing irrelevant detail.

Something happened between pages 13 and 14.

Section 5.2 introduces libraries. How do they get invoked? How are they bound? Are the directories discussed here the same directories as elsewhere? This section does not give enough information to be called the ``Implementation.''

Section 6.1.2 has a useful example. Is this code written by a person, a program, or both? It's not C.

The second paragraph on page 17 hints at something more general than what is described there.

Section 6.1.3 answers a question that came up on page 9, which is symptomatic of the organization of the paper.

Section 6.2 describes the sort of flexibility that justifies the system, which needs to be explained better and placed much earlier in the paper. The last paragraph and the figures are far too weak to be convincing.

Section 6.3 is vacuous. Something important is being hinted at here, but the discussion is too general to be interesting.

Section 7.1.1 points out the shortcomings of storing trees as UNIX directories. These shortcomings are obvious enough to be discussed or dismissed when the notion is first mentioned on page 10.

The acknowledgements mention ``many potential nodes.'' What are they? After a long paper introducing a structure, too little detail of the result is presented to justify all the work. More of the system must exist than is explained here. The paper should make much clearer what is going on, how it's done, and where it leads.

The reference Haeb86 names the Proceedings of the Proceedings.

This paper is difficult to understand.