jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/24/91)
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 m0154@tnc.UUCP (GUY GARNETT) (03/26/91)
This is a Dard Good Idea! Because I like this idea so much, I will write up the spec, if no one else volunteers to (there are many other people on this group who are much more qualified to do it than I am). I have a couple of observations: How about generalising it to a conversions utility. One of the good features of the Mac is that it has such a thing built into its clipboard; you can clip something out of one program, and paste it into another, usually without worring about it. If implemented as an independent task (perhaps with a support library), the conversions module could be made even more flexable. Properly implemented, the conversions facility would be able to support most (or all?) of the current amiga standards (including internal formats, like the Intuituion Image), and be extensible, so that by adding some modules to a drawer somewere, the user could install support for tomorrows formats as well. Here is what I am thinking of: A host process which manages one or more message ports (for receiving conversion requests). A shared library of conversion tools (routines for managing conversion requests, the conversion message ports, and support routines for the convertors) to reduce the memory consumption of the whole thing, and a set of convertors. Each convertor supports one kind (or a limited set of similar kinds) of conversion (for example, PostScript to Image, or another one which converts DR2D to IFF). Each one has some parameters which it uses to control the conversion, and input and output data formats. The conversion facility maintains a list of convertors, and can load them from disk, order them to shut down or start a conversion, and generally provides overall management. (Presumabley, the it can scan the convertors on disk to determine which kinds of conversions it can support; no reason to require all of the convertors to be loaded in RAM at once). This would also allow programs (like word processors or DTP software) to request a printer-resolution version of an "unknown" format. The program would simply request a conversion into a bitmap at the appropriate resolution, and then include the bitmap with the rest of the printer data. A set of convertors which output PostScript would allow printing on PostScript laser printers. Items for Discussion: Programmer's interface - how to request conversions, how to present the item to be converted, and select conversion options. There needs to be a standard interface, because a program written to use the conversion facility may need to convert a format which didn't exist when the convertor or the application program was written. Convertor interface - So that applications programmers can write a set of convertors for their product. Again, a standard interface, so that the convertor will work with products which haven't been created yet. Developer Co-Operation - For this scheme to work, each software developer will need to create a set of convertors for their product (for example, ProWrite to IFF, ProWrite to PostScript, ProWrite to ASCII, ProWrite to FTXT, etc). While this is a little extra work, it will (hopefully) add value to your product. If your (Word Processor, Paint Program, Cad Package, Spreadsheet, whatever) supports the Conversion Facility, then people who own a (DTP Program, etc ..) which also supports it will want to buy your product (since they know that they can then exchange data between the two programs). "Hot Conversions" - What about when two Conversion Facility using applications are running at once? Should they be able to pass data from application-to-application through the convertor (so you can edit that bitmap, and pass it back, for example). Additional Standards: Do some additional standard formats need to be defined (for example, what do you do with formatted text? or what about 3D objects?. My feeling is that the first three items (Programmer and Convertor interface, and Developer Co-Operation) are critical. The other two (Hot Conversions and Additional Standards) can safely be shelved. Sorry for the long post, but this is a good Idea, and we need to get working on implementing this thing. The Amiga has been without it for far too long. Wildstar
robbel@fwi.uva.nl (Robert Belleman) (03/26/91)
m0154@tnc.UUCP (GUY GARNETT) writes: >This is a Dard Good Idea! > >Because I like this idea so much, I will write up the spec, if no one >else volunteers to (there are many other people on this group who are >much more qualified to do it than I am). I have this strange feeling in the stomach, guys ... I think this scheme is a VERY BAD IDEA ... read on ... >I have a couple of observations: > >How about generalising it to a conversions utility. One of the good >features of the Mac is that it has such a thing built into its >clipboard; you can clip something out of one program, and paste it >into another, usually without worring about it. And do you know _why_ you don't have to worry about it ?? Because Apple designed QuickDraw; a Picture Definition format that covers just about everything that anyone would ever like to do with graphics. Most Mac- program only supports ONE renderer : QuickDraw. >If implemented as an independent task (perhaps with a support >library), the conversions module could be made even more flexable. >Properly implemented, the conversions facility would be able to >support most (or all?) of the current amiga standards (including >internal formats, like the Intuituion Image), and be extensible, so >that by adding some modules to a drawer somewere, the user could >install support for tomorrows formats as well. Just think about this; for every ~new~ format that comes into existence a new conversion utility has to be written to convert into ANY other format that exists to that date !! How long do you think software developers can keep that up ??! [lots of stuff deleted ...] >Sorry for the long post, but this is a good Idea, and we need to get >working on implementing this thing. The Amiga has been without it for >far too long. I agree on that last point; I think the Amiga needs something that the Mac has had from the beginning. I believe it's a better idea to work on a Amiga version of the QuickDraw library and MAYBE design converters to THIS format. Who knows; the format you come up with might even be so good that it will be an Amiga standard ... If you like, look at it as a intermediate graphic format, I don't care ... >Wildstar -- Rob Robert Belleman, University of Amsterdam. (robbel@fwi.uva.nl) -- Robert Belleman, University of Amsterdam. (robbel@fwi.uva.nl)
jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/27/91)
robbel@fwi.uva.nl (Robert Belleman) writes: >[...] > >I have this strange feeling in the stomach, guys ... I think this scheme >is a VERY BAD IDEA ... read on ... > > >I have a couple of observations: > > > >How about generalising it to a conversions utility. One of the good > >features of the Mac is that it has such a thing built into its > >clipboard; you can clip something out of one program, and paste it > >into another, usually without worring about it. > >And do you know _why_ you don't have to worry about it ?? Because Apple >designed QuickDraw; a Picture Definition format that covers just about >everything that anyone would ever like to do with graphics. Most Mac- >program only supports ONE renderer : QuickDraw. Yes. And look at the hassles you get when dealing with PostScript or TIFF files. The strength of this idea is that any format imaginable could be used in any progam, provided that it makes sense for such an image to be rasterized in the first place. >>If implemented as an independent task (perhaps with a support >>library), the conversions module could be made even more flexable. >>Properly implemented, the conversions facility would be able to >>support most (or all?) of the current amiga standards (including >>internal formats, like the Intuituion Image), and be extensible, so >>that by adding some modules to a drawer somewere, the user could >>install support for tomorrows formats as well. > >Just think about this; for every ~new~ format that comes into existence >a new conversion utility has to be written to convert into ANY other format >that exists to that date !! How long do you think software developers can >keep that up ??! It shouldn't be necessary to write more than one rasterizer/renderer. If you can convert your graphic into an intuition image, it should be possible to, if desired, make a converter to take it from an intuition image to any bitmapped format. So if you have a new format, you'd have one to take it to an intuition image, and one to take it from an intuition image. And if this conversion can be done at a program's behest, during execution, then wonderful things become possible. I am not myself in favor of overextending the concept to mandate direct conversion routines from any two standard formats. I liked Lou Cavallo's (I hope I am correct as to attribution here) proposal for its simplicity, even as much as its power. I'd personally like to see it also support whichever gfxbase structure is required to allow for the renderer to support the Amiga printer drivers, but that I suspect that one could go from an Intuition image to a bitmap quite easily. (I don't recall, but I suspect that the printer drivers take a bitmap, and that the Intuition image structure has a pointer to a bitmap.) >>Sorry for the long post, but this is a good Idea, and we need to get >>working on implementing this thing. The Amiga has been without it for >>far too long. > >I agree on that last point; I think the Amiga needs something that the Mac >has had from the beginning. I believe it's a better idea to work on a Amiga >version of the QuickDraw library and MAYBE design converters to THIS format. >Who knows; the format you come up with might even be so good that it will be >an Amiga standard ... > >If you like, look at it as a intermediate graphic format, I don't care ... The real power of Lou's idea is that any program could support any graphics format in a very straightforward manner. An Amiga version of object oriented QuickDraw would have great advantages where you don't want to go about rasterizing your image at the Amiga level, and would prefer to send it out for PostScript. This would be a much more extensive piece of work to perform, however, and is something that could be put into place if such a program-independent rendering scheme was in place. My preferences, as I mentioned before and above, would be for their to be a class of rendering devices which could be mounted as graphics engines for printing, but which also have non-standard i/o functions for providing bitmap/intuition image rendering for programs. Preferences could be set to control whether sending a GIF file to the gif: device would open up a custom screen and show the image, or whether it would go to the default printer. Things that come to me off the top of my head for parameters for such a thing would include color depth, desired image quality (approximate rendering time/quality weighting -- draft, better, best? 8-), image size, predefined palette/number of palette colors available for allocation, aspect ration, dot pitch, source of image (file, clipboard, pointer to in-memory image). In addition, I suspect it would prove prudent to allow a mechanism for additional information for such things as view point, etc. if heavy duty rendering support is to be added to this. Something like an extended IOStdReq structure or something. Of course, this would go over wonderfully with AREXX, as you could have your program AREXX over to a screen grabber or a Video Toaster, or a digitizer or what have you, which would then create a file or save a clip, which your program could then have rendered. I'll have to go home and look up the printer device in my RKM's, as well as intuition image structure, etc. to get a bit more familiar with some of these details. >-- >Robert Belleman, University of Amsterdam. >(robbel@fwi.uva.nl) -- ------------------------------------------------------------------------------- Jonathan David Abbey \"Take your place on the great Mandela" P,P&M the university of texas at austin \ jonabbey@cs.utexas.edu "Love me, love computer science/math?/psychology? \ (512) 472-2052 my Amiga" -Me
pete@violet.berkeley.edu (Pete Goodeve) (03/27/91)
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 --
peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/27/91)
There are obviously two aspects in this issue: One, the general idea of
renderer utilities (appreciated, ok); two, the file format question.
For the latter, the great Guru says: ALWAYS USE IFF! Someone mentioned
ease of use on the Mac with its clipboard: Also the Amiga has a clipboard,
and the defined file format to use there is indeed IFF! So, why invent
again something new? Let every renderer utility work ONLY on IFF. Let
there be some conversion utilities for the few other formats existing,
plus to convert between HAM and plain palette and 24-bit modes. For
what would you need more???
BTW, is it the IFF that makes the Amiga clipboard the most unused
feature ever known?
--
Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions...
Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterkdillon@overload.Berkeley.CA.US (Matthew Dillon) (03/28/91)
In article <1991Mar27.080423.22023@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >In article <1214@muleshoe.cs.utexas.edu> Jonathan Abbey says: >>.. Probably the best way to implement this sort of stuff is through dynamically linked object modules. That is, a running program makes a library call to dynamically link in an arbitrary object module. I have written a library to do this, although it is still somewhat primitive (and likes to run under 2.0). The concept is simple -- you simply link your main program with symbols and the dynamic loader finds the executable and picks out the symbols, then dynamically links in the requested object module, providing pointers to requested symbolic functions as a result. Thus, one simply defines the interface calls and support routines required (since the dynamically linked object module can link to any of the program's symbols, such as Move(), Draw(), printf(),...). Any third party can write object modules using the interface spec for a particular job (like converting or displaying images in one format or another). -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/28/91)
In article <1017@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >There are obviously two aspects in this issue: One, the general idea of >renderer utilities (appreciated, ok); two, the file format question. >For the latter, the great Guru says: ALWAYS USE IFF! Someone mentioned >ease of use on the Mac with its clipboard: Also the Amiga has a clipboard, >and the defined file format to use there is indeed IFF! So, why invent >again something new? Let every renderer utility work ONLY on IFF. Let >there be some conversion utilities for the few other formats existing, >plus to convert between HAM and plain palette and 24-bit modes. For >what would you need more??? [First, an apology to Lee Willis.. I misattributed his post to Lou Cavallo in my last post.. ^_^] 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. 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. >BTW, is it the IFF that makes the Amiga clipboard the most unused >feature ever known? Probably so.. having to whip up a FTXT FORM to save text is a little much for many programmers, particularly when there has not been an IFF library available. >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk -- ------------------------------------------------------------------------------- Jonathan David Abbey \"Take your place on the great Mandela" P,P&M the university of texas at austin \ jonabbey@cs.utexas.edu "Love me, love computer science/math?/psychology? \ (512) 472-2052 my Amiga" -Me
m0154@tnc.UUCP (GUY GARNETT) (03/28/91)
In article <1991Mar26.154335.16403@fwi.uva.nl> robbel@fwi.uva.nl (Robert Belleman) writes: >m0154@tnc.UUCP (GUY GARNETT) writes: >>Properly implemented, the conversions facility would be able to >>support most (or all?) of the current amiga standards (including >>internal formats, like the Intuituion Image), and be extensible, so >>that by adding some modules to a drawer somewere, the user could >>install support for tomorrows formats as well. > >Just think about this; for every ~new~ format that comes into existence >a new conversion utility has to be written to convert into ANY other format >that exists to that date !! How long do you think software developers can >keep that up ??! > I don't think you understood what I was proposing. I was not proposing that modules be written to support every possible combination of "input" and "output" file formats. As you pointed out, that would require entirely too many modules. What I *AM* proposing is that the conversions utility be able to convert *FROM* almost anything *TO* a limited number of Amiga "Standards" (about half a dozen would be a good number) like Intuition Image structures, rendering to RastPorts or BitMaps, IFF (ILBM and 8SVX seem the be most useful), and text (ASCII, ANSI ASCII, IFF FTXT, and PostScript would be most usefull). What about IFF DR2D and support for 3D objects? In this way, an Applications programmer need only make his program understand the applicable formats, and have an interface to the conversions module. This way, a data object in any conversions-supported format could be converted to one of the "Standard" formats for display and printing in the application. All any one programmer has to do is write about half a dozen small conversion modules (and maybe even fewer) for each custom data format that his software *CREATES*. Public Domain programmers will probably take care of the balance (IFF to whatever convertors, etc). The advantage of this method is that support for the conversions facility is reatively easy to adto an existant program (especially if it already knows now to deal with ASCII and IFF, let's say). Conversion modules should be similarly easy, with each application needing to supply only a few (and again, these should be short, and the programmer may be able to re-use code from his application). >>Sorry for the long post, but this is a good Idea, and we need to get >>working on implementing this thing. The Amiga has been without it for >>far too long. > >I agree on that last point; I think the Amiga needs something that the Mac >has had from the beginning. I believe it's a better idea to work on a Amiga >version of the QuickDraw library and MAYBE design converters to THIS format. >Who knows; the format you come up with might even be so good that it will be >an Amiga standard ... > >If you like, look at it as a intermediate graphic format, I don't care ... > >>Wildstar > >-- Rob > >Robert Belleman, University of Amsterdam. >(robbel@fwi.uva.nl) I don't think that an Amiga quickdraw is a useful effort. Existant programs will not be able to support it without major coding changes, and this alone would probably doom such an effort to obscurity. Quickdraw works on the Mac because almost everything destined for the screen goes through the QuickDraw system at some point. Althoh this allows the Mac to do some of its magic, it also places restrictions on Mac programmers. Amiga programmers are used to being able to directly access their screen bitmaps; removing this ability would probabily be unacceptable. If nobody used the standard, it would not have the effect we are looking for (easy interchange of data between programs). If the set of output formats for the conversion facility is relatively small and well-chosen, it will become relatively easy to implement while providing great additional value to the product. This spells success to me, and to most software developers (this is the same reason that Arexx has enjoyed the success it has: an Arexx port is relatively easy to add to a program, and enhances its value immensely). Wildstar
m0154@tnc.UUCP (GUY GARNETT) (03/28/91)
When I proposed extending the conversions utility, I was thinking about a couple of things. One is that such a utility would be useful not only for graphics, but also for other data formats. I agree that the number should be limited to something "reasonable", and not all conversions are possible (it does not make any sense to try to convert audio data to anything but an IFF sound format, for example). One conversions facility could manage all of this activity, supplied with the proper conversion modules. One of the other things I was thinking about was the case of relatively high-end packages which are sending their ouptut to something other than a Preferences printer driver. In such case getting the data converted into PostScript (the usual language of choice for high-quality printed output) is much more desirable. For example, you have a CAD drawing which is embedded in the document. For display on screen, the conversions utility is used to render it to an Image (or whatever else is appropriate) at the proper scale for screen display. When the time comes to print that, instead of printing the raster image (which will either consume oodles and oodles of RAM as the converter tries to render it to a huge bitmap at 300 pixels per inch, or will look horrible as postscript scales the bitmap up by a factor of four or so) it would be very desirable to have another module to convert it to encapsulated postscript, to be sent to the printer along with the rest of the page. Similarly, when converting a wordprocessor's save file into a DTP application, the user may want to be able to treat it as text, rather than as a graphic image. Such a conversion module should be relatively easy to write, and should require almost no additional overhead in the conversions utility itself. This way, non-graphic files can be converted into useful non-graphic formats. The trick will be to define the set of supported conversions properly, to get the maximum utility out of the thing. Output formats we should at least consider are: Bitmapped Graphics (including Image and IFF), Structured Graphics (2D and 3D), Text (including plain ASCII), and PostScript. Wildstar
hill@evax.arl.utexas.edu (Adam Hill) (03/28/91)
Here is my two cents worth.
First we should worry about a "XXX to a IFF bitmap (Intuition Image
structure) that is in Box x1,x2,y1,y2" Keep that baby as modular as
possible for addition of printer support. After we get 2 or 3 of these
libraries done we need a a text editor (PD? - Textra? or Commercial? -
ProWrite?) to support it. If CBM doesn't bless the spec PD might be
the only way to go.
(whew) After this we should take a vacation.....
Just keep in mind that we want to add to it when you start on the
spec.
--
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 SVR4BAXTER_A@wehi.dn.mu.oz (03/29/91)
In article <1017@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > There are obviously two aspects in this issue: One, the general idea of > renderer utilities (appreciated, ok); two, the file format question. > For the latter, the great Guru says: ALWAYS USE IFF! Someone mentioned > ease of use on the Mac with its clipboard: Also the Amiga has a clipboard, > and the defined file format to use there is indeed IFF! So, why invent > again something new? Let every renderer utility work ONLY on IFF. Let > there be some conversion utilities for the few other formats existing, > plus to convert between HAM and plain palette and 24-bit modes. For > what would you need more??? > > BTW, is it the IFF that makes the Amiga clipboard the most unused > feature ever known? Because: It has been very buggy, especially in low memory conditions. It has had no structured drawing format. Its bit map format results in huge data transfers which make it slow. No "Rich text file" format was implemented. C= did not provide any system support of the clipboard: No debugging tools No Snap like utility No bit map visualisation - like is there any way of viewing a bit map in the clipboard now??? The "professional" developers have developed internal cut/paste mechanisms and kept data structures secret, along with their file formats. But I guess you knew all that... Regards Alan
jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/29/91)
Okay, I've done some more thinking on this, and here's roughly what I've been thinking about: I've really become sold on the IPC way of doing this thing. Here's a general sceme I could envision: IFF ____________ PostScript____ \ TIFF_________ \ \ GIF ________ \ \ \ FLI _____v \ \ \ \ __________________ |-------------->|RENDERER MODULES|-------->IFF file ANIM ____/ ------------------ __________ _____ ^| | \ IFF / ______V______________ v \ IFF || |Display \______/ |IFF TO DISPLAY STRUCT| _________ |____/ | |Struct --------------------- |CLIPBOARD|--------|-|------------------------^ ___/ | --------- | \________________________/_____ | | _____________________/ v v _________|____/ ------- |Master Control|_------------------ |Display| -------------- \ ------- \ \ \_______ ------------|Program| ------- This gives the basic structure. Renderer modules would take commands from Master Control, which would handle requests from the program to provide rendering support. Renderer modules would have two paths of output. The first a direct dump to bitmap for purposes of high speed display directly in a program's bitmap or super bitmap. The second method would be generation of an IFF FORM which would be rendered to the display structure by a dedicated module. This would provide support for non-bitplanar displays or other non-standard displays that could arise in future systems. A new IFF to Display structure module would be written to support a new system. The IFF to IFF to DISPLAY path could take complete forms, or it could conceivably support open ended IFF files, with an END chunk indicating close of transmission. Things like DLTA chunks or CMAP chunks could be sent at a later time, while the display structure is publicly available. Extensions to this could include feedback (mouse clicks, and what have you) to the renderer from the program through the master control. A renderer could draw "gadgets" in the display structure and interact with the user if the program were to transmit mouse clicks taking place in the display structure through master control to the renderer. Master control would determine if there were a renderer that could go directly to display structure, or that it would be necessary for the renderer to dump to IFF and go through an IFF to DISPLAY module. This diagram does not have a printer involved, but an IFF to printer module could be added in a position analagous to the IFF to display module. For support of object based graphics files like PostScript, you could have something that would roughly fit in the diagram where the renderer modules are, which would convert an object oriented file to PostScript or vice-versa, which could then be output as a file or dumped to a PostScript printer. There is a lot of handwaving hidden in here, obviously. 8-) -- ------------------------------------------------------------------------------- Jonathan David Abbey \"Take your place on the great Mandela" P,P&M the university of texas at austin \ jonabbey@cs.utexas.edu "Love me, love computer science/math?/psychology? \ (512) 472-2052 my Amiga" -Me
pete@violet.berkeley.edu (Pete Goodeve) (03/29/91)
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 --
pete@violet.berkeley.edu (Pete Goodeve) (03/29/91)
In <dillon.5617@overload.Berkeley.CA.US> (27 Mar), Matthew Dillon (dillon@overload.Berkeley.CA.US) writes: > > Probably the best way to implement this sort of stuff is through > dynamically linked object modules. Nope, I don't think I agree with you there, Matt. Dynamically loaded modules are a nice idea all right, but I don't think they're so suitable for this purpose. The problem as I see it is flexibility. Unless you have a good match between the symbols in your program and the dynamically loaded stuff (in both directions) you're going to have some nasty hanging references. When you write your "top-level" program you have to make sure that you've satisfied ALL the references that the dynamic stuff might need. And different Renderers would probably have different requirements. Could get messy. With something like ppIPC on the other hand, both ends of the link are much more independent. You can expand facilities at one end without immediately worrying about the other. A renderer can do the best it can, even if there are some parts of the request it doesn't recognize. At the other end, the client doesn't have to be concerned with advanced features of the renderer that it doesn't need (or the author didn't even know about). As long as the interface (message format) is properly defined and observed, everything should work fine. Another advantage of a separate process is that it can be serving more than one client at a time, as opposed to code that is loaded into a program. An off-the-top-of-the-head example: suppose you had a renderer that could handle anims, but a paint program (with access to the renderer) that couldn't, and a showanim display module. You could flip between viewing the anim, and grabbing frames of it for retouching, without reloading anything. -- Pete --
hill@evax.arl.utexas.edu (Adam Hill) (03/31/91)
In article <dillon.5617@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > > Probably the best way to implement this sort of stuff is through > dynamically linked object modules. That is, a running program > makes a library call to dynamically link in an arbitrary object > module. I have written a library to do this, although it is > still somewhat primitive (and likes to run under 2.0). > > The concept is simple -- you simply link your main program with symbols > and the dynamic loader finds the executable and picks out the > symbols, then dynamically links in the requested object module, > providing pointers to requested symbolic functions as a result. > > Thus, one simply defines the interface calls and support routines > required (since the dynamically linked object module can link to any of > the program's symbols, such as Move(), Draw(), printf(),...). > Any third party can write object modules using the interface spec > for a particular job (like converting or displaying images in one > format or another). > > Matthew Dillon dillon@Overload.Berkeley.CA.US Matt, This sounds like a AWSOME IDEA. If the code is going to be PD, I for one vote we should use it. We could even write a .DXF file translation module for Matt's CAD program. :-) -- 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