Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jonabbey From: jonabbey@cs.utexas.edu (Jonathan David Abbey) Newsgroups: comp.sys.amiga.programmer Subject: Intuition Image structure rendering utilities Summary: World Class Good Thing Keywords: rendered intuition image PostScript IFF Message-ID: <1214@muleshoe.cs.utexas.edu> Date: 24 Mar 91 05:22:19 GMT Organization: U. Texas CS Dept., Austin, Texas Lines: 135 The following was posted on .advocacy, but the thread of discussion seems to have died out in favor of insightful discuss of Mark Barret's last post, and this really seems like too much of a Good Thing to allow to die thusly. So I am reposting this here without any sort of permission, etc. -------------------------------------- From: Lee_Robert_Willis@cup.portal.com Newsgroups: comp.sys.amiga.advocacy Subject: IDEA: Rendering utilities! Message-ID: <40434@cup.portal.com> Date: 22 Mar 91 00:49:53 GMT Organization: The Portal System (TM) Lines: 99 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.com --------------END OF INCLUDED MATERIAL----------------------------------------- One comment I have is that this same sort of concept could go really nicely with printer drivers as well. Perhaps such renderers could serve as high level printer drivers (i.e., post: and the like) that would also support the kind of thing discussed above as new device driver io commands? Heck, perhaps outline fonts could get in on the scheme in some fashion. Anyone willing to draft a spec? 8-) -- ------------------------------------------------------------------------------- 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