Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!uakari.primate.wisc.edu!caen!uwm.edu!bionet!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: renderer intuition image PostScript IFF
Message-ID: <1991Mar29.064127.10066@agate.berkeley.edu>
Date: 29 Mar 91 06:41:27 GMT
References: <1991Mar26.154335.16403@fwi.uva.nl> <1017@cbmger.UUCP> <273@atacama.cs.utexas.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 81


In  <273@atacama.cs.utexas.edu> (27 Mar),
Jonathan David Abbey (jonabbey@cs.utexas.edu) writes:
> The idea is that the renderer would deal with the file format, and that the
> program would receive a bitmap/rastport/intuition image ready-to-use.
> Certainly I would want IFF used for any and all file storage and transmission,
> but there would be no cost and much gain from building renderers that could
> support non-IFF file formats, particularly PostScript, say.

I think I also lean towards concentrating on conversion to bitmap-image,
at least initially.  Obviously there's a place for conversion of anything
to anything, but if one embarks on a quest for the "Specification of
Everything" it's gonna take a while.  The main thing is to make one's
initial development open-ended and flexible, so it doesn't prevent
extending it as one wants later.  Start with IFF-to-bitmap, then add
other formats to the basic scheme.

>
> Pete G., ppIPC sounds interesting.. do you feel that it would be suitable
> for such a renderer scheme?  Do you think that it could be extended to
> support SANA?  I'm not familiar with the SANA spec myself, but it would
> be nice if we had a clean path to networking with this thing a little
> later on.

Thanks.  Yes, I do think that at least the protocol is exactly right for
the interface to a renderer.  Of course, the "Renderer" I wrote was nothing
special.  I just took someone else's ILBM reader code from an early Fish
disk, and attached the IPCMessage stuff with a few nails and a piece of
string (:-)).  I don't think I'd even use it as the basis of a proper one;
better to start from scratch.

The thing about the IPCMessage format is that it's flexible.  The requesting
("Client") program can include just the items it's concerned with -- no
need for a fixed structure in which half the slots are empty.  For example,
if it wanted Dither of some kind, it would include a `DTHR' (maybe) item;
if this was missing, the renderer would simply do its default thing.
Similarly for raster size and so on.  The only essential items would
probably be the slot (maybe slots?) for the image itself, and the reference
to the ILBM -- or whatever -- to be converted.  This last should have a
number of alternative possibilities: filename (FILN), filehandle (FILH),
in-memory ILBM (ILBM?, IFF?) and maybe others.  FILN & FILH are already
standard IDs; the others would have to be decided upon.  (They are 32-bit
words, like IFF IDs, but not so firmly wedded to four-letter-upper-case.)

I have never found any reason why ppIPC should be incompatible with SANA.(:-))
Their areas of concern are a bit different, despite both being tagged with
the label "IPC".  (A pity, but when we started on ppIPC there really WAS
no standard for the Amiga -- not even ARexx.)  SANA is essentially a
Device -- addressed by IORequests and so forth -- oriented to connecting
two processes across a network (though both processes MAY well be on the
same machine); it is not concerned with the contents of the data.  On the
other hand, ppIPC is strictly within machine -- just an extension of Exec
message passing -- and its main concern is to ensure that the data is
identified.

This means that the constraints are rather different.  When you pass data
across a network, you pass DATA (in a stream of packets, usually); within
a machine it is much faster to pass POINTERS.  Things that ppIPC can be
perfectly happy with -- like memory addresses, of Ports or chip-memory
raster images perhaps -- may be meaningless to pass across a network.

However, a lot of the data contained in IPCMessages is NOT meaningless
to pass across a network, as long as you're willing to copy it to the
other end.  Even chip-memory images are fine to pass, as long as the system
KNOWS that they have to be put back in chip memory to be useful at the
other end.  No way, on the other hand, can you pass a list structure
directly: you have to do a lot of massaging at both ends.

One of the first things we put into ppIPC therefore was a `NETWORK' flag
bit.  If this is set, a server knows that it is safe to pass the referenced
data as a block across the net.  If it is not, it still may be possible
for servers that understand the ID to pass it, but they had better know
what they are doing!

What would be needed to couple ppIPC to SANA would be a general purpose
server (maybe more than one) that converted IPCMessages to/from SANA
streams.  SANA is not concerned at all with structure of data (it just
reads and fills buffers) so some convention would have to be adopted
for identifying the data passed.

                                        -- Pete --