Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: Intuition Image structure rendering utilities Keywords: rendered intuition image PostScript IFF Message-ID: <1991Mar27.080423.22023@agate.berkeley.edu> Date: 27 Mar 91 08:04:23 GMT References: <1214@muleshoe.cs.utexas.edu> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: University of California, Berkeley Lines: 162 In article <1214@muleshoe.cs.utexas.edu> Jonathan Abbey says: > >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 >Subject: IDEA: Rendering utilities! >Message-ID: <40434@cup.portal.com> >Date: 22 Mar 91 00:49:53 GMT > > [....] > >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. > >Some obvious Renderer candidates: > > IFF_ILBM.renderer > IFF_DR2D.renderer > ProDraw.renderer > PostScript.renderer > Sculpt3D.renderer > etc. > Yep, I think it IS a good idea. It's not entirely new, though. It's exactly the sort of scheme I intended ppIPC for. In fact, for my talk on ppIPC at BADGE (what -- nearly three years ago, now) I hacked up a slideshow that included what is pretty much an ILBM renderer as one of the several interacting programs that managed the show. I never published the code or the executables because, frankly, it WAS hacked up in a hurry to do the job, and I'd want to clean it up a lot before I let other people use it. It did work, though, and made for a very successful show. The setup I had was (approximately) like this: Command ---------------------------| Client---------------| ---------------------->Screen v | Server Script Manager | | --------------->ILBM Manager The connections indicate the flow of messages between the programs; they are all actually bidirectional (messages always being replied back to their originator), but the arrows show which way the main request messages are passed. The Command Client was the process (or one of them, actually -- I'll return to that) that I would tell -- via the keyboard in this case -- what I wanted to happen next. It simply converts the keyboard commands into standardized messages that it sends to the Script Manager at the centre of it all. The Script Manager is the bit that does most of the work, reading -- on request from the command client -- the script (list of ILBM files to be shown), deciding which pictures should be preloaded, requesting them from the ILBM manager, and sending them -- when actually commanded to do so -- to the Screen Server for display. The Screen Server simply has the job of displaying the (in-chip-memory) bitmap/colormap messages it is sent. It switches to a new image when it receives it -- or returns to the workbench if so instructed. The ILBM Manager is the equivalent of the Renderer idea. When requested (by the script manager in this case) it converts the wanted file directly into a chip-memory image, which it passes back to the requestor for it to do with as it likes. It has the additional function -- for convenience -- of being able to dispose of the image and recover the memory, so that the script manager doesn't have to bother with that. It simply says to the ILBM manager, "Dump this..." Of course this isn't a full implementation of a Renderer as in Lee Willis's suggestion. The format of the bitmap is determined strictly by the ILBM that generates it, not by request of the client, and so on, but the basic idea is the same, I think. I mentioned that there are other possible sources of input. The thing is, as long as the Script manager gets a suitable standard command at its command port, it doesn't care where it came from. One such source is the Screen server process, which includes a mouse-click processor: a click on the right sends "next slide", one on the left sends "previous slide". Another alternative is a joystick. And all these sources can be running at once. The role of ppIPC in all this [as usual..(:-)] is to provide a standard format for messages that can safely handle all the various kinds of data being passed around, from simple commands to complete bitmap and colormap structures, and also to provide safe and speedy linkage between the separate programs. Command messages, you should note, aren't text that needs parsing (that's done only in the command client), just IDs and code values that can be handled with a case statement or two. The messages that pass image data are a lot more complex -- that's why I let the ILBM Manager handle the disposal -- and probably with some thought could be refined from the particular way I did them, but the principle is the same. Standard format `IPCItems' in the message, with their own specific IDs, point directly to the bitmap, the individual bitplanes, and the colormap. As I said, this was a hacked up, experimental scheme, so there were a lot of complexities I won't bother to get into. Things have gotten a lot more standardized since then and should be a perfect fit into a Renderer project. ---------------------------------------------------------------------- Okay... One more time! ["...this is your brain on IPC..."] Those who have heard it all too many times before can skip the rest, but for those who DON'T know about ppIPC... It is a (sort of!) standard protocol hammmered out mostly here on the net originally about three years back, that aims for speed, safety and common ground in passing data of any kind between independent processes. IPCPorts -- managed independently of any particular process -- let individual processes join and leave the activity without hazard. IPCMessages are of a standard, but highly flexible, structure that makes it easy for a receiving program to decode and process them unambiguously, or reject any that it is not prepared to handle. The protocol takes care of such things as handing over or retaining ownership of data blocks, so that memory doesn't get freed improperly, or never! It differs sharply in philosophy and purpose from Arexx. It isn't a language in any way -- just a protocol, written into programs. It is not oriented just towards passing and interpretation of text strings, but rather data of all kinds. It is as fast as Exec message passing (which it uses of course) will permit, yet is much safer than the basic Exec mechanism. There is no central interpreter process, just a small (2.6K) resident shared library, used by any program that wants to participate. There are other modules that may optionally be involved, such as a "Port Broker" that will automatically launch any process needed to service a requested port. And, of course, it is freely available to all. Fish disk #290 is one place. ---------------------------------------------------------------------- -- Pete --