Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!spool.mu.edu!munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!u3364521
From: u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: IDEA: Rendering utilities!...(LONG)
Message-ID: <1991Mar22.233101.1746@ucsvc.ucs.unimelb.edu.au>
Date: 22 Mar 91 13:31:00 GMT
References: <40434@cup.portal.com>
Organization: I.A.E.S.R., Melbourne University
Lines: 110

G'day,

In article <40434@cup.portal.com>, Lee_Robert_Willis@cup.portal.com writes:
> 
> I was using ProWrite the other day, and wishing that it would import 
> ProfessionalDraw files, when the following thought occurred to me:

  Yep, sigh, if the program hasn't got the option to do a thing then what
  can we do but ...

> What we (the Amiga community) need is class of programs that I term
> "Renderers" (this has nothing to do with PIXAR's RenderMan).
>
> A "Renderer" is a program which takes a graphic file, and creates 
> an Image structure (Intuition bitmap) for a client application. 

  The idea IMHO is a good one but if it is paraphased as building up new
  functionality into an application using modular s/w components one can
  see the idea is not new.

  However I think Lee is seeing the shape of the Amiga future here where
  he is asking for integrability of "snap in" s/w components for any s/w
  an Amiga user might purchase off the shelf (with respect to image ren-
  dering in this case).

> When a client program wants to display an image, it starts up the
> renderer (if its not already resident), and sends it a message 
> which contains the filename of the image to render, the width, height,
> and depth of the desired result, whether to scale or clip the image
> if it doesn't fit perfectly, what kind of dithering (if any) to use,
> etc.

  I'm going to go out on a limb here and suggest that some s/w (such as
  The Art Department/AdPro) already works in this modular way but not in
  a way (perhaps it does?) that address Lee's Renderer concept.

> The renderer reads the file, and creates an Intuition Image structure, 
> which it returns to the Client application.  (It is the clients 
> responsibility to deallocate the returned message)

> [... flow diagram and suggested messaging mechanism ...]

> Client applications would generally be programs which display images, 
> but don't manipulate them.  e.g., Pictures in a word processor, or DTP
> program,  Multimedia programs (AmigaVision).

  Why not manipulate the images with the Renderer?

> The client would store reference to the image, and its renderer.  (Similar
> to the way Project icon .info files store a reference to the icon's file
> and default application) 

  Kind of a HyperDocument idea eh? :-) {I can imagine the images "hotlinked"
  to a Renderer with simple drawing and text annotation abilities that allow
  images in a document to be touched up rather than separately in a painting
  or drawing program. (Lee suggested the same thing basically, I am just off
  on a tangent re: hotlinking a single image into 1 or more applications..)}

> Some obvious Renderer candidates:
> 
>       IFF_ILBM.renderer
>       IFF_DR2D.renderer
>       ProDraw.renderer
>       PostScript.renderer
>       Sculpt3D.renderer
>          etc.

  GIF.renderer, PICT.renderer, TIFF.renderer ... ?

> The beauty of this concept is that it allows applications to be 
> open-ended.  A word processor that supports the "Renderer" interface 
> can potentially handle *any* graphic format!  The end result is the
> same (an Image).  

  Yep ... and a happy user.

> [... AmigaVision/CanDo multimedia type examples ...]

> I know that with some applications this can sort-of be accomplished now
> using AREXX.  e.g. run the graphic application using AREXX, save the image
> to an IFF file, read in the IFF file in the client.  But I think the 
> Renderer has the following advantages over AREXX:
>
> [... I agree with all your suggested advantages but I'm cutting them ...]
> [... to trim this reply a little.                                    ...]

> A renderer should be freely distributable.  (Just like there are freely 
> distributable ILBM displayers, SMUS players, text readers)

  Yes.  I feel however that this style of integrability of s/w components
  has to have support from the major s/w producers within their products.

  Currently a s/w producer has a commercial edge if their s/w can import
  more types of objects than their competitors can and so ... one asks if
  this idea will obtain support from the big s/w producers when it is not
  in their *short term* interests to support it?

  Are other computer architectures dealing with these types of ideas? How
  are the s/w producers collaborating if this is so?

> So thats my idea.  Comments?

  I hope my own above have been useful. I have one final comment however
  which is that in an ideal world we'd have only one Graphics format and
  would only require a single Renderer. :-)

> Lee      Lee_Robert_Willis@cup.portal.com

yours truly,
Lou Cavallo.