From: Tristan Wibberley <bloater@ps.cus.umist.ac.uk>
  To  : ggi-develop@eskimo.com
  Date: Thu, 4 Feb 1999 15:37:22 +0000 (GMT)

Re: libggi3d non-clarity

On Wed, 3 Feb 1999, Aaron Gaudio wrote:

> And lo, the chronicles report that X. Bouchoux spake thusly unto the masses:
> > 
> > (I haven't the time to read the last mail.)
> > 
> > just an idea to name the interfaces:
> > 
> > I think that just chaining types may be unsufficient. (think for example to clipping: the data in input and output are the same, just lee
> > less in output than in input.  So the actual fonction performed by the module is not apparent with its type)
> 
> This makes perfect sense. There is no way to try to explain in any 
> objective, efficient way what a module does to the data it is given, just
> as in C you couldn't do this. Contract-programming (Eiffel, for example) is
> a neat idea, but it is very limited in scope and produces very significant
> runtime overhead.
> 
> In the case of clipping, whatever organizes the pipeline will have to know where
> to put clipping in the pipeline; all an arbitrator would do is make sure
> that where the clipping module goes, the interfaces match up correctly.
> 
> GGI3D is not supposed to replace human intelligence in forming the pipeline,
> it's merely supposed to allow the human to extend/recreate/tweak the pipeline
> easily.

I'm a little confused as to what would happen when draing on a target that
can render a circle quickly itself. The app would have to just make the
pipeline as 'drawcircle -> target' rather than it's usual 'drawcircle ->
tesselate -> rasterise -> target' or whatever. Would GGI3d provide a
default pipeline that leaves out unnecessary bits?

--
Tristan