The FRAMES paper is fine as an introduction to the system for potential users, but mostly avoids discussion of topics that would make it a good contribution to a technical conference. Section 2 rightfully takes other systems to task but the rest of the paper doesn't continue to put the contributions of FRAMES in this perspective. Instead, it rapidly turns into little more than a list of simple examples, much as in a user's manual, that convince the reader that FRAMES can make simple images but make no claims about the complex images that traditionally interest SIGGRAPH readers.

FRAMES is a modular, simple way to make images. If you are trying to convince readers that the method is successful, and you should be, you will need to explain how the simple design does not forestall complex images. Instead, the examples in the paper show that the simple design can make many different kinds of simple images. Both points need to be made, but you are only making one of them. As it stands, people will turn elsewhere for guidance on the construction of production renderers. You might even consider being feisty and taking on the (published) monolithic renderers explicitly.

To be fair, the idea of rendering as a pipeline is not a novel one. What might be novel is the power you achieve from a particular design for that structuring. But to make the paper worthwhile, you must tell how you use the idea: what you gain, what you lose, what you learned.

You must give up some things. It costs more to use pipes, both because of packing and unpacking data and the cost of pipes themselves as compared to, say, function calls. There must be programming overhead due to the necessity to pass unused information along for a later element in the pipeline. Do you lose some robustness? One bad process can destroy the whole picture by a small mistake that would only corrupt a pixel or two in a different environment. Finally, you give up some sorts of type checking that would happen if you were writing the system as a single program. Problems can occur not only at the interface between programs, but at the interface between different programmers writing them.

In other words, don't take the pipeline model as a given, justify it with some solid information and insight. You think the model is worthwhile, but it takes more than mere examples to convince a skeptic.

One worrisome property of the system is the use of a single data representation (almost) throughout. More information needs to be given on this and other design decisions you made. When does a single representation get in the way? How bad is the overhead of converting to and from this format? Why do you consider the tradeoffs to fall this way? For example, you don't store pictures in this format; abuf produces a run-length encoded output. What can you tell the reader about how similar decisions should be made?

The English is fairly good, at least by computer science standards. The following is a list of specific comments.

Section 2 is good, particularly in passages such as the end of the paragraph about Blinn's system.

Section 4 is the bulk of the paper, and doesn't deserve to be. It's much too long and either too tutorial (long lists of simple variations) or too detailed (the format of error messages). The whole section should take a couple of pages at most. Make your points, give a few examples to drive them home, and move on. By Section 4.6 we're solidly convinced that elements of the pipeline can be replaced for experimentation. Perhaps the long lists of programs could be compressed into a table.

The bullet list in Section 4.1 is particularly uninteresting. After describing the language, you should spend more time explaining why it has that design than giving formats for messages from UNIX. Also, the timing numbers in this section seem to be making a point, but it's not clear what the point is, or at least why it matters. Say what's on your minds.

The catalogs in Section 4.? should largely be replaced by a description of the benefits of this structure. Giving lists of possibilities requires the reader to induce what the system can do. Why not just say? What are the limits? What are the drawbacks? What are the benefits? How are different filters written? Is there a subroutine library they share to read and write files? What programming language are they written in? Why was that choice made? Does the repeated I/O processing in this approach cause trouble? If the benefits of the architecture make this overhead worthwhile, say what the benefits are (not just by giving some more examples) and explain why you're content with the result.

In 4.4, the phrase ``A fast Phong shader could be implemented by cat ....'' is symptomatic: you don't say anything about how it could be implemented, just how it could be used. It's not that we need to see the formulas again, but that we need to know how to use the formulas in your system.

``The current shader specified in the input file is active until another is specified.'' This sounds like a bad idea, especially given all the programs that could insert or delete things in the data. Surely you have ways of guaranteeing trouble doesn't happen. What are they?

Section 4.5 talks about several ``options'' to the camera program. Why are they options to one program instead of separate programs? How do you decide when to modify an existing program or write a new one?

Section 4.6 is weak. Why did you choose a-buffers? Why are the four computations (scan conversion, visibility, shading and antialiasing) folded into one program? Again, we need more information about why you chose to do things this way. The second paragraph on page 10 is a muddle. You're either saying too much or not enough there. Further down the page, what does ``for our purposes'' mean? You haven't said anywhere just what your purposes are, which makes it hard to decide why your design decisions were made the way they were. Why appeal to them now? Your reference to Duff [8] to back up statements about linear separation is misguided. Duff's algorithm has problems within a pixel, but has no difficulty with intertwined objects per se. Finally, the pictures you present are not complex enough to justify what sounds like a difficult implementation. The long list of examples down page 11 should be greatly compressed.

Section 4.6.1: How do you control back removal per-object? If you can't, does this bother you?

Section 5 is particularly expansive. Device independence is a dead horse. Don't beat it any longer than to say your pipeline makes it possible to have device independence and still exploit hardware to perform some of the calculations (by leaving off some elements of the pipeline). The use of ``filtering'' on the top of page 13 is confusing.

Section 6: It's not your fault, but the term ``Distributed Rendering'' is possibly confusing. You would be justified in sticking with it, though. The last sentence of this section doesn't belong in this paper.

Section 7 needs more convincing examples and some performance figures, preferably comparing performance with other systems.

The list of directions in Section 8 says too little to be interesting. If you have interesting comments to make on how these extensions are made easy and useful by your architecture, say them. Otherwise the section is vacuous.

The last sentence of Section 9 is horrible.

The references should not include unpublished manuscripts and internal AT&T documents.