Lee_Robert_Willis@cup.portal.com (03/22/91)
I was using ProWrite the other day, and wishing that it would import
ProfessionalDraw files, when the following thought occurred to me:
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.
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.
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)
Return_Address,
___________ filename, _____________
/ \ Rendering_parameters / \
| Client | ------------------------> | |
| Application | | Renderer |
| | <------------------------ | |
\___________/ Image \_____________/
Return_Address ::= Message Port of client application
which is expecting the image.
filename ::= file name of image to render.
Rendering_Parameters ::= Width, Height, Depth,
Colors, Dithering, etc.
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).
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)
Some obvious Renderer candidates:
IFF_ILBM.renderer
IFF_DR2D.renderer
ProDraw.renderer
PostScript.renderer
Sculpt3D.renderer
etc.
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).
Or imagine an AmigaVision flow (or CanDo application) which allows
the user to browse the blueprint of a building. The blueprint is
in some vector-drawing program format. When the user clicks on
zoom, pan, or scroll gadgets, the renderer is called to re-render
the image at the new point of view. At the click of another button,
a 3D modelling renderer creates a 3D image of the building at the
current location.
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:
A renderer executable can be much smaller, because there's no
user-interface.
A renderer will be faster because there's no IFF formatting and
parsing. (and no disk I/O)
Given that a standard interface/required functionality is defined,
a renderer will be easier to use. The user does not have to learn
AREXX (I know its not hard, but I'm a programmer, and if you're reading
this, so are you :-) Remember that there are plenty-o-people who
can't program their VCR) The user would merely have to type into
a requester:
Image File : My_Picture
Renderer : PostScript
and if DefaultRenderer is a ToolType in the picture's icon, the
user shouldn't even have to supply the Renderer!
A renderer should be freely distributable. (Just like there are
freely distributable ILBM displayers, SMUS players, text readers)
So thats my idea. Comments?
Lee Lee_Robert_Willis@cup.portal.comu3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (03/22/91)
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.
jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/23/91)
A WONDERFUL, wonderful idea! Who do we talk to get some kind of official interface defined/blessed? Please! -- ------------------------------------------------------------------------------- Jonathan David Abbey \"I am stronger than the passing time" -Frost the university of texas at austin \ jonabbey@cs.utexas.edu "Love me, love computer science/math?/psychology? \ (512) 472-2052 my Amiga" -Me
Dickson@system-m.phx.bull.com (Paul Dickson) (03/23/91)
Isn't there an IFF parser included with AmigaDOS 2.0? Wouldn't be
better to have the renderer's output in the same format as this parser.
Then an application would only have to be able to handle sending of
parameters to the renderer that would be different from the IFF parser
and in other cases, the data from the renderer could be redirected to
the IFF parser to generate an IFF image disk file.
-Paul Dicksonhill@evax.arl.utexas.edu (Adam Hill) (03/23/91)
One of your "renderers" exists now -- Post 1.5 by Adrian Aalward
(sp?). Thomas Rockki (sp?) of Amiga TeX fame is using it to add
transparent Postscript support to TeX (No more Grey Boxes!! Yea!)
Since most formats are widely availible it seems like a NEAT
shareware project (Even neater than the MSDOS "transpiler"). You could
even go one step further. Write a "object --> iff" library to render
standard (circle, bezier splines, N-splines, spheres, cubes, do
dithering etc..)
Now if there were 30 hours a day........
--
adam hill -- hill@evax.uta.edu ASOCC - University of Texas at UTA
I programmed for three days Make Up Your Own Mind.. AMIGA!
And heard no human voices. Amiga... Multimedia NOW!
But the hard disk sang. - TZoP Born To Run SVR4